Go Modules的前世今生

以前，Go语言的依赖包的管理一直被诟病，Go官方从最初的GOPATH到GO VENDOR，再到目前的GO Modules，一直在努力提供更方便的包管理方案。

目前最主流的方案是官方推荐的GO Modules。先介绍一下以前的GOPATH和GO VENDOR，了解它们的发展历程，才能知道GO Modules多么来之不易。

1、      古老的GOPATH

配置环境的时候对其应该都不陌生，可以将其理解为“工作目录”。

工作目录下通常有如下目录：

将自己或者别人的包全部放在$GOPATH/src目录下来管理的方式，就称为GOPATH模式。

在此模式下，使用go install，生成的可执行文件会放在$GOPATH/bin下。

如果安装的是一个库，则会生成.a 文件到 $GOPATH/pkg 下对应的平台目录中。

 

使用GOPATH去开发程序有个最严重的问题，就是版本管理问题，因为GOPATH根本没有版本的概念。

 

会遇到的问题：

u  无法在你的项目中，使用指定版本的包，因为不同版本的包的导入方法都一样；

u  其他人运行你的开发的程序时，无法保证他下载的包版本是你所期望的版本，当对方使用了其他版本，有可能导致程序无法正常运行

u  在本地，一个包只能保留一个版本，意味着你在本地开发的所有项目，都得用同一个版本的包，这几乎是不可能的

 

2、      Go vendor模式的过渡

为了解决GOPATH模式下不同项目下无法使用多个版本库的问题，Golang从v1.5开始支持vendor。

以前使用GOPATH的时候，所有项目都共享一个GOPATH，需要依赖的时候，都来这里找，在GOPATH模式下只能有一个版本的三方库。

Vendor模式的思路就是为每个项目都创建一个vendor目录，每个项目的依赖都下载到自己的vendor目录下，项目之间的依赖包互不影响。编译时，默认开启vendor特性，相较于GOPATH，提升vendor目录的依赖包搜索路径的优先级。

搜索包的优先级顺序：

（1）    当前包下的vendor目录‘

（2）    向上级目录查找，直到找到src下的vendor目录；

（3）    在GOROOT目录下查找；

（4）    在GOPATH下面查找依赖包

 

此方案的不足：

（1）    如果多个项目用到了同一个包的同一个版本，这个包会存在于该机器上的不同目录下，不仅对磁盘空间是一种浪费，而且没法对第三方包进行集中式的管理（分散在各个角落）。

（2）    如果要分享开源你的项目，你需要将你的所有的依赖包悉数上传，别人使用的时候，除了你的项目源码外，还有所有的依赖包全部下载下来，才能保证别人使用的时候，不会因为版本问题导致项目不能如你预期那样正常运行。

 

3、      Go mod的横空出世

go modules 在 v1.11 版本正式推出，在最新发布的 v1.14 版本中，官方正式发话，称其已经足够成熟，可以应用于生产上。

从 v1.11 开始，go env多了个环境变量： GO111MODULE，这里的 111，其实就是 v1.11 的象征标志， go 里好像很喜欢这样的命名方式，比如当初 vendor 出现的时候，也多了个GO15VENDOREXPERIMENT环境变量，其中 15，表示的vendor 是在 v1.5 时才诞生的。

GO111MODULE 是一个开关，通过它可以开启或关闭 go mod 模式。

它有三个可选值：off、on、auto，默认值是auto。

（1）GO111MODULE=off禁用模块支持，编译时会从GOPATH和vendor文件夹中查找包。

（2）GO111MODULE=on启用模块支持，编译时会忽略GOPATH和vendor文件夹，只根据 go.mod下载依赖。

（3）GO111MODULE=auto，当项目在$GOPATH/src外且项目根目录有go.mod文件时，自动开启模块支持。

 

开启go mod就将GO111MODULE设置为on。比如可以：

go env –w GO111MODULE=”on”

 

4、      go mod依赖的管理

初始化时，会多出go.mod文件；执行安装，会下载依赖包并且完善go.mod文件生成go.sum文件。

go mod会将下载的依赖包都安装到$GOPATH/pkg下，生成的可执行文件在$GOPATH/bin下。

          

    go.mod和go.sum是go modules的核心所在。

²   go.mod：

go.mod的内容比较容易理解，第一行就是模块的引用路径，第二行就是项目所用的go版本，第三行就是项目所需的直接依赖包及版本。

有时会看到更加复杂的go.mod文件：

exclude表示忽略指定版本的依赖包，replace表示替换库。

²   go.sum：

go.sum文件比较复杂：

每一行其实都是由模块路径、模块版本、哈希检验值 组成的。哈希检验值是用来保证当前缓存的模块不会被篡改。Hash是以h1:开头的字符串，表示生成检验值的算法是第一版的哈希算法。

 

值得注意的是，有点包只有一行，有的包有两行：

有两行的包，区别在于hash不一致，一个是h1:hash, 一个是go.mod h1:hash。h1:hash和go.mod h1:hash要不就是同时存在，要不就是只有go.mod h1:hash。什么情况下会没有h1:hash呢？就是当GO认为肯定用不到某个模块版本的时候就会省略它的h1:hash。

go.mod 和 go.sum 是 go modules 版本管理的指导性文件，因此 go.mod 和 go.sum 文件都应该提交到Git 仓库中去，避免其他人使用你的项目时，重新生成的go.mod 和 go.sum 与你开发的基准版本的不一致。

 

5、      go mod命令的使用

u go mod init

初始化go mod，生成go.mod文件，后可以接参数指定module名。

u go mod download

手动触发下载依赖包到本地缓存（默认$GOPATH/pkg/mod目录）

u go mod graph

打印项目的模块依赖结构

u go mod tidy

添加缺少的包，删除无用的包

u go mod verify

校验模块是否被篡改过

u go mod why

查看为什么需要依赖

u go mod vendor

导出项目的所有依赖到vendor下

u go mod edit

编辑go.mod文件，接 -fmt 参数格式化 go.mod 文件，接 -require=golang.org/x/text 添加依赖，接 -droprequire=golang.org/x/text 删除依赖，详情可参考 go help mod edit

u go list –m –json all

以 json 的方式打印依赖详情

 

6、      如何给项目添加依赖写进go.mod

法（1）：只要在项目中import，然后go build，go module就会自动下载并添加；

法（2）：自己手动使用go get下载安装后，会自动写入go.mod