关于管理依赖 依赖管理
Go依赖管理的演进：
GOPATH → Go Vendor → Go Module
GOPATH
go语言有一个内置的全局环境变量GOPATH，指定了GOPATH文件夹后，他会在这个文件夹内创建以下三个文件夹：
bin：项目编译的二进制文件
pkg：项目编译的中间产物，加速编译
src：项目源码
项目直接依赖src下的代码，go get命令下载的软件包都会在src目录下。
关于GOPATH的缺点
当我们对某个依赖进行升级后，则项目A依赖的版本可能无法实现兼容，这就是GOPATH无法解决的多版本控制问题
为了解决多版本控制问题，go又增加了Go Vendor的方式来管理依赖。
使用govendor init 在项目根目录会生成vendor文件夹，其中存放了当前项目依赖的副本。在Vendor机制下，如果当前项目存在Vendor目录，会优先使用该目录下的依赖，如果依赖不存在，会从GOPATH中寻找；这样解决了更新GOPATH依赖源码后之前的版本不兼容的问题。
Go Vendor弊端
弊端很明显，无法解决依赖的依赖。
同样还是无法解决依赖的冲突，归根到底vendor不能很清晰的标识依赖的版本概念。
Go Module （最终解决方案）
特点：
- 通过 go.mod 管理依赖包版本。
- 通过 go get/mod 工具管理依赖包。
最终目标：定义版本规则和管理项目的依赖关系。 而管理依赖三要素是：
- 配置文件，描述依赖 （对应go.mod）
- 中心仓库管理依赖库 （GoProxy）
- 本地工具 go get/mod
版本规则 gopath和govendor都是源码副本方式依赖，没有版本规则概念，而gomod为了放方便管理则定义了版本规则。
对于语义化版本有如下规则：
MAJOR：表示是不兼容的 API，所以即使是同一个库，MAJOR 版本不同也会被认为是不同的模块。 MINOR：通常是新增函数或功能，向后（向下）兼容。 PATCH：修复 bug。
