"做讨厌潮汐的稚童，祈祷月球失踪。"
一、背景
我们写一个程序，例如输出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代理服务器 下载依赖包。
单纯潦草地写写。感谢你的阅读。
