Go依赖管理

"做讨厌潮汐的稚童，祈祷月球失踪。"

一、背景

我们写一个程序，例如输出hello world 或者 一个猜数字游戏，这些用到的单体函数接口，只需要依赖一些原生的SDK即可。但是，面对复杂的实际问题、工程，仅依赖这些原生的东西是不够的，因为我们需要关注的不仅仅是 业务逻辑的实现，还涉及到日志log，框架等等，需要引入其他sdk配合整体项目功能的实现、运行信息的完善。因此，对这些依赖包引入的管理，显得尤为重要。

Golang在解决依赖包管理的历史有三个阶段，也衍生为解决依赖包问题的三个版本，GOPATH / GOVENDER / GO MODULE。不同的环境，适合的依赖管理版本也不同。

二、$GOPATH

Golang本身就可以利用自己的能力，解决依赖包的管理。

(1)GOPATH目录

GOPATH是一个工作环境,是go语言支持的一个环境变量。此目录下存放正在开发的代码，编译后的依赖包，依赖包的源码以及可执行文件(bin)。

默认路径(win10):

• bin 用来存放编译后的二进制文件

• pkg用来存放编译后的归档文件(加速编译)

• src 用来存放我们源代码和下载的第三方依赖

(2)Go命令工具

go get;

下载依赖包的最新版本到GOPATH指定目录

go install;

一般在项目目录下执行此命令，项目需要包含main package和func main入口函数。

go build;

编译成二进制可执行文件。

(3)GOPATH的弊端

如果GOPATH能够解决实际中的所有问题，也就不会有另外两个版本的出现。

我们知道，GOPATH会把所有项目所用到的库放在同一个文件pkg当中。如果此时Pro

A依赖 库v1版本,而ProB依赖库v2的版本,但是src下只能支持一个版本的存在。

1.在使用go get的时候,无法知道拉取的 依赖包是什么版本。
2.多人协作时，无法不保证你自己与人家的第三方库使用的是同一个版本。
3.当你拉取包下来的时候，你无法处理不同版本包的引用问题。

三、Go Vender

为了解决依赖管理中的遗留问题,Go引入了vendoring机制。简单来说，就是把项目中依赖到的模块，直接拷贝到项目目录中，跟随项目源码一起做版本管理。

在vendor机制下，会优先使用目录中Vender的依赖。如果依赖不存在，则会去GOPATH中寻找。

(1)Go Vendor的弊端

此时的项目A依赖pkg 1，2。而,pkg1、2又分别依赖pkg3、4,这两个版本用Vendor的管理方式不能很好的控制依赖包的版本。从而，到编译项目的时候，又会出现依赖错误。

四、Go Moudle

Go mod目前是Go的官方解决方案，解决了GOPATH、GOVENCOR遗留的依赖管理的问题，和无法依赖同一个库多个版本的问题。

(1)管理三要素

• 配置文件、描述依赖关系go.mod

• 中心仓库存储、分发依赖 Proxy

• 本地工具 go get/mod

进行项目创建时，在配置文件go.mod中声明依赖版本，去中心仓库Proxy下载对应的版本包到本地，并进行编译。

可以看出，这样做就实现了 项目依赖的包不是代码，而是代码的版本,而对这个代码版本的控制，也就成了对配置文件的管理。从而，实现从编码 与 版本控制之间的解耦。

(2)配置文件go.mod

在项目的根目录下，记录当前依赖包信息的普通文件。

这里的GOMOD出现了两个声明依赖的格式。

module: 模块名
go指令的版本号

任意一个依赖单元用： 模块路径+版本来唯一标识。

(3)Proxy中心仓库

因为源代码仓库拥有者可以对自己的源码增删查改，那么势必会对正在使用这些代码的人有影响。为了解决这一个问题，go便引入了Proxy中心仓库，作为缓冲，来解决这种不稳定性。

(4)本地工具

go mod;

module语句指定包的名字（路径）
require语句指定的依赖项模块
replace语句可以替换依赖项模块
exclude语句可以忽略依赖项模块

使用go mod的包管理方式，依赖的第三方包被下载到了$GOPATH/pkg/mod路径下

go get;

// 为当前项目拉取依赖
// 下载的依赖包放到缓存中，并在go.mod文件中新增一条require记录
go get example.org/pkg

向Proxy代理服务器 下载依赖包。

单纯潦草地写写。感谢你的阅读。