这是我参与「第五届青训营」笔记创作活动的第6天

必要性

开发项目时要有效利用开发组件进行或工具提升自己的研发效率

对于较简单的单体函数而言，只需要依赖原生的SDK即可完成开发

对于实际开发的工程较于复杂，应将精力投放在实现的业务逻辑之上

工程项目不可能基于标准库0-1编码搭建
管理依赖库

两个路径（GOROOT、GOPATH）

安装go sdk,配置go环境变量
Go env 查看环境变量
- GOROOT： sdk安装目录
- GOPATH：项目路径

在 vendor 目录、GOPATH 目录、GOROOT 目录都可能存在依赖库(标准库、第三方库等)

1 . GOPATH 模式

$GOPATH ：项目根路径
- src ：项⽬源代码
- bin ：可执行程序
- pkg ：第三⽅依赖库

运行方式

所有工程代码要求放在GOPATH/src目录下工程本身也将作为一个依赖包，可以被其它 GOPATH/src 目录下的工程引用
在 $GOPATH/src 下进行 .go 文件或源代码的存储，我们可以称其为 GOPATH 的模式

缺点

没有版本控制的概念
所有项目都要放在 GOPATH/src目录下，不在 GOPATH/src 下就不能编译

2. vendor 特性/模式 (三方）

解决 GOPATH模式所有项目都在$GOPATH/src目录的问题
可以随处可以创建项目，不用扎堆 src 目录下

方案原理：本地化构建
在每个项目下都创建一个 vendor 目录，每个项目所需的依赖都只会下载到自己vendor目录下.
在使用包时，会先从当前项目下的 vendor 目录查找，然后GOPATH 中查找，都没找到最后在 GOROOT中查找。
缺点
放弃了依赖重用，使得冗余度上升

3. Go Modules 模式

可以管理依赖的版本
工程不用全放在gopath/src

主要改动：

GOMODULE模式下所有依赖的包存放在 $GOPATH/pkg/mod目录下项目中需要有go.mod文件，来应用$ GOPATH/pkg/mod

mod 相关环境变量

GO111MODULE="auto"
# Go 模块代理（脱离VCS版本控制方式，直接通过镜像站点来拉取）
GOPROXY="https://proxy.golang.org,direct" # 国内无法访问
# 保证拉取到的模块版本数据未经过篡改
GOSUMDB="sum.golang.org" # 国内无法访问
# 私有模块配置（用于Go 模块代理无法访问到的地方，如私有库）
GONOPROXY=""
GONOSUMDB=""
GOPRIVATE=""

两个命令

go get xxx（下载xxx第三方依赖包并安装）

go get会做两件事：

从远程下载需要用到的包
执行go install安装

go install xxx（安装xxx二进制可执行文件）

go install 是建立在 GOPATH 环境变量上的，无法在独立的目录里使用 go install。

go install 会生成可执行文件直接放到bin目录下

版本变化

go install = 用来编译安装本地项目。
go get = 下载 Go 包 + go install

go 1.16
go get 将二进制安装相关的功能都转移到了 go install, 仅作为用于编辑 go.mod 文件的命令存在。
go 1.17
开始官方不建议(deprecated)用于安装二进制可执行文件，不能使用 go get 命令安装 Go 程序了
go 1.18
开始不再支持安装。选项-d未来将成为默认参数，仅执行下载，不进行安装
go get 的行为就等同于我们现在执行 go get -d 命令了，仅需下载源码，并将依赖添加至 go.mod

总结

GO项目的依赖管理在目前基本使用gomod，我在学习的过程中参照着java的maven来进行，比较了二者的异同，有不少收获。

GO依赖管理 ｜ 青训营笔记

必要性

两个路径 （GOROOT、GOPATH）