1. 介绍
自 Go 1.6 起，vendor 机制正式启用，它允许把项目的依赖放到一个位于本项目的 vendor 目录中，这个 vendor 目录可以简单理解成私有的 GOPATH 目录。 项目编译时，编译器会优先从 vendor 中寻找依赖包，如果 vendor 中找不到，则再到 GOPATH 中寻找。
2. vendor 目录位置
一个项目可以有多个 vendor 目录，分别位于不同的目录级别，建议每个项目只在根目录下放置一个 vendor 目录。
假如有一个 github.com/test/testcase 项目，项目目录结构如下：
GOPATH/src/github.com/test/testcase/testpackage/main/main.go
其中 main.go 中依赖如下几个包：
import (
"golang.org/x/crypto/ssh"
"github.com/pkg/sftp"
)
在没有使用 vendor 目录时，若想编译这个项目，则 GOPATH 目录经过应该如下：
GOPATH/src/github.com/test/testcase/ GOPATH/src/github.com/pkg/sftp GOPATH/src/golang.org/x/crypto/ssh
即所有依赖的包都位于 GOPATH/src 下。
为了把所使用到的 golang.org/x/crypto/ssh 和 github.com/pkg/sftp 版本固化下来，可以使用 vendor 机制。
在项目 github.com/test/testcase/ 根目录下创建一个 vendor 目录，并把 golang.org/x/crypto/ssh 和 github.com/pkg/sftp存放到此目录中，让其成为项目的一部分：
GOPATH/src/github.com/test/testcase/testpackage/main/main.go GOPATH/src/github.com/test/testcase/vendor/github.com/pkg/sftp/ GOPATH/src/github.com/test/testcase/vendor/golang.org/x/crypto/ssh/
使用 vendor 的好处是在项目 github.com/test/testcase 发布时可以把其所依赖的软件一并发布，编译时不会受到 GOPATH 目录的影响，即便 GOPATH 下也有一个
同名但不同版本的依赖包。
3. 搜索顺序
编译器会从源码文件所在的目录开始逐级向上搜索，在上面的例子中，在编译 main.go 时，编译器搜索依赖包的顺序为：
- 从
GOPATH/src/github.com/test/testcase/testpackage/main/下寻找 vendor 目录，没有找到，继续从上层查找。 - 从
GOPATH/src/github.com/test/testcase/testpackage/下寻找vendor 目录，没有找到，继续从上层查找。 - 从
GOPATH/src/github.com/test/testcase/下寻找 vendor 目录，从 vendor 目录中查找到依赖包，结束查找。
如果 GOPATH/src/github.com/test/testcase/ 下的 vendor 目录中没有依赖包，则返回 GOPATH 目录继续查找。这就是 GOPATH 机制了。
实际上 vendor 目录可以存在于项目的任意目录下。但是不推荐，如果 vendor 目录过于分散，则可能同一个依赖包在项目的多个 vendor 中出现
多次，这样依赖包会多次编译进二进制文件，从而造成二进制文件的体积急剧增大，也很可能出现一个项目中使用同一个依赖包的多个版本的情况。
4. vendor 的不足
vendor 很好地解决了多项目间的隔离问题，但是也有一些不足之处：
- 项目依赖关系不清晰，无法清楚地看出
vendor目录中依赖包的版本。 - 依赖包升级时很不方便审核。
更严重的是二进制文件的体积急剧增大的问题，比如项目依赖开源包A和B，但是A中也有一个vendor目录，其中也放了B，那么项目中将出现两个开源包B。
如果两个开源包B的版本不一致或者不兼容，那么后果非常可怕。
vendor 能够解决大部分项目中的问题，但是也存在很多的不足之处。
