因为之前一直是 C++ Coder，根本没有所谓的包管理，项目依赖一塌糊涂，说到 C++ 的不便之处还得吐槽一句，编译速度贼慢，每次项目中写完代码等待编译的时候就想着，以后再也不想用 C++ 写代码了。
说回正题，go mod 包管理工具
没有包管理之前，项目管理会出现什么问题
在没有包管理方案之前，项目依赖于 GOPATH，这样带来一些不便之处：
多项目难以管理。试想一下，A 项目和 B 项目 同时依赖于一个 C 项目，但是依赖于 C 项目的不同版本，如何解决，只能通过多 GOPATH 设置。
项目的依赖只能够手动 go get 下载到 GOPATH 中，如果换一台服务器开发项目，光是包依赖都得弄半天。
go mod 出来之前，其他方案的是怎么设计的？
godep，glide，go verdor 这些都是曾经出现过的包管理解决方案。
挑 go vendor 说一下，他是如何解决上面的两个问题的。
对于多项目，他是在项目中创建一个文件夹 vendor，将项目的依赖都放在里面，这样就实现了多项目分开管理依赖。
对于手动下载包，他会将项目依赖的信息和版本统一记录在一个文件中，这样迁移环境只需要执行特定命令就能将依赖包都下载到 vendor 文件夹中
在 go mod 出来之前，go vendor 包管理模式是受很多大牛推崇的，也是非常好的方案。
当然也有一点小瑕疵：
- 多个项目都依赖于同版本的 A 项目，则 A 项目需要冗余存储多份。
go mod 是怎么设计的？
既然 go vendor 已经成熟了，为什么不直接扶正呢，因为 google 爸爸有自己的想法。
这就是我们今天的重点 go mod 包管理方案。
go mod 和 go vendor 类似，有统一的目录管理包依赖，但是是统一放在 $GOPATH/pkg/mod 里面，对于多版本管理见下图。
和 go vendor 一样，项目中有文件记录项目的包依赖和版本号，go.mod 和 go.sum
go mod 使用篇
常用命令：
go mod graph 把模块之间的依赖图显示出来
go mod init 初始化模块（例如把原本dep管理的依赖关系转换过来）
go mod tidy 增加缺失的包，移除没用的包
go mod vendor 把依赖拷贝到 vendor/ 目录下
go mod verify 确认依赖关系
go mod why 解释为什么需要包和模块
go mod 启用的三种模式
- on：开启 Go mod 模式
- off：关闭 Go mod 模式
- auto (默认模式)：如果代码在gopath下，则自动使用gopath模式；如果代码不在gopath下，则自动使用GO mod模式。
大陆额外福利
经常会有一些包，比如 golang.org/x/net 等，无法直接下载。
只需要添加环境变量即可
export GOPROXY=https://goproxy.io
一起愉快的用 go mod 吧
使用例子：
初识RPC
示例代码地址 go-micro-demo
