0、包管理的历史
Golang 的包管理一直被大众所诟病的一个点，但是我们可以看到现在确实是在往好的方向进行发展。
下面是官方的包管理工具的发展历史：
- 在 1.5 版本之前，所有的依赖包都是存放在 GOPATH 下，没有版本控制。这个类似 Google 使用单一仓库来管理代码的方式。这种方式的最大的弊端就是无法实现包的多版本控制，比如项目 A 和项目 B 依赖于不同版本的 package，如果 package 没有做到完全的向前兼容，往往会导致一些问题。
- 1.5 版本推出了 vendor 机制。所谓 vendor 机制，就是每个项目的根目录下可以有一个 vendor 目录，里面存放了该项目的依赖的 package。go build 的时候会先去 vendor 目录查找依赖，如果没有找到会再去 GOPATH 目录下查找。
- 1.9 版本推出了实验性质的包管理工具 dep，这里把 dep 归结为 Golang 官方的包管理方式可能有一些不太准确。关于 dep 的争议颇多，比如为什么官方后来没有直接使用 dep 而是弄了一个新的 modules，具体细节这里不太方便展开。
- 1.11 版本推出 modules 机制，简称 mod，也就是本文要讨论的重点。modules 的原型其实是 vgo，关于 vgo，可以参考文章末尾的参考链接。 https://research.swtch.com/vgo
1、go mod是什么？
go mod 是Golang 1.11 版本引入的官方包（package）依赖管理工具，用于解决之前没有地方记录依赖包具体版本的问题，方便依赖包的管理。
之前Golang 主要依靠vendor和GOPATH来管理依赖库，vendor相对主流，但现在官方更提倡go mod。
总结一下：
- 从go 1.11开始支持
- 可以不需要gopath存在
- 环境变量GO111MODULE，默认为auto
- 项目存在go.mod则使用go module,否则使用GOPATH和vendor机制
2、依赖管理
1）为什么需要依赖？
我们想复用已有的工作成果。
将已有的工作成果加入我们项目中作为依赖存在太多的不确定性：
包API的变化；包内部行为变化；包的依赖会变化；包已经不存在或无法访问；包与包之间的不同依赖相互冲突等
随着软件开发规模的逐步增大，涉及到的外部依赖越来越多，手动管理的所有依赖愈发不可能。所以我们需要依赖管理，我们需要有个工具或者规范来描述和定义包与包之间的依赖关系，并自动化的去处理、解析和满足这些依赖。
3、基本使用
1）环境准备
Golang 版本：1.12.3。在 1.12 版本之前，使用 Go modules 之前需要环境变量 GO111MODULE:
- GO111MODULE=off: 不使用 modules 功能。
- GO111MODULE=on: 使用 modules 功能，不会去 GOPATH 下面查找依赖包。
- GO111MODULE=auto: Golang 自己检测是不是使用 modules 功能。（默认）
2）初始化go module环境
带git的项目：go mod init
不带git的项目：go mod init packagename
3）下载依赖包
只下载依赖包
go mod download
拉取必须模块，移除不用的模块
go mod tidy
注意点：
- 如果tag对应内容有更新，需要删除pkg中的缓存内容。
- cd $GOPATH/pkg/mod rm -rf *
- go get、go run、go build 也会自动下载依赖
4）添加新依赖包
方法一：直接修改go.mod，然后执行:go mod download
方法二：使用go get packagename@v1.2.3，会自动更新 go.mod 文件
方法三：go run、go build也会自动下载依赖
5）将依赖包下载到vendor目录
go mod vendor
注意：只会下载对应版本的包文件，不会下载所有版本
4、总结
1）大部分场景 go mod init 和 go mod tidy就够了
2）查看$GOPATH/pkg/mod里面的文件就知道了，mod做了一件类似maven的事把所有包都打上了版本号。
解决多版本问题困扰。
