起源
最早的时候，Go所依赖的所有的第三方库都放在GOPATH这个目录下面。这就导致了同一个库只能保存一个版本的代码。如果不同的项目依赖于同一个第三方的库的不同版本，应该怎么解决？
答案是把第三方库复制到项目中去。同时需要重写import的路径，也就是把原本依赖的GOPATH下面的路径改写成项目的路径。如果第三方库本身还依赖于别的项目，情况就变得更加复杂。更加蛋疼的是，同一套的代码，在不同的机器上，由于机器上第三方库版本的不同，会产生不同的行为。这在多人合作的项目中是没办法接受的。
转机
到了Go1.5版本，终于出现了转机。官方支持了vendor机制。
所谓支持vendor，其实就是在每个项目中增加了一个特殊的名叫vendor的目录。
Go在引入的时候，会按照以下顺序去寻找第三方库。
- 当前包下的vendor目录。
- 向上级目录查找，直到找到src下的vendor目录。
- 在GOPATH下面查找依赖包。
- 在GOROOT目录下查找
这种机制给了每个项目多一点的自主权，他们再也不用看整个Go环境的脸色了，终于拥有了自己选择自己想要的第三方库版本的自由。
管理
出现了vendor机制后，就涌现出了许多包管理工具。这些工具的基本原理大致相同。
- 解析项目中依赖的第三方库；
- 指定第三方库所用版本；
- 拉取第三方库代码到vendor目录下。
问题
目前这种解决方式存在一个问题，就是会产生大量第三方库的副本。当然，现在机器配置基本上不在乎这些硬盘消耗，所以这个问题大概也不是什么大问题。因此，官方似乎也没打算花力气解决这个问题。
