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 能够解决大部分项目中的问题，但是也存在很多的不足之处。
到此这篇关于Go中Vendo机制的使用的文章就介绍到这了,更多相关Go Vendo内容请搜索恩蓝小号以前的文章或继续浏览下面的相关文章希望大家以后多多支持恩蓝小号！
原创文章，作者：WLKSV，如若转载，请注明出处：http://www.wangzhanshi.com/n/5524.html
