go1.11的module机制和dep/govendor机制问题

module机制和dep/govendor机制是否冲突？

自从 go 团队推出 module 机制后，go团队和dep社区发生了一些冲突，有一篇有名的争论《关于Go Module的争吵》，读后给人一种错觉，似乎 module 机制和 dep/govendor 机制是不相容的。但是仔细分析二者的运行机制，其实两者并无冲突，反而是互补性质的。

module 机制由环境变量 GO111MODULE 控制，它有三个值： off、on、auto ，默认值是 auto 。在 auto 模式下，在 $GOPATH/src 路径下 build 时，默认使用 vendor 、 GOPATH 导入第三方包，而在 GOPATH 之外编译时，默认使用 go.mod 设置导入项目。我们知道 vendor 机制只有在 GOPATH 路径之下才起作用，到了 GOPATH 之外就没用了。所以 module 机制可以看作是 vendor 机制的一个补充，在 GOPATH 之内，它可以和 dep/govendor 一样把依赖包导入 vendor 目录，同时它又提升了go语言的灵活性，我们的源代码不再必须保存到 GOPATH 中，可以灵活组织目录结构。

什么情况下使用 module 机制？

• 当你依赖的所有第三方包都通过 git 服务器托管的时候，非常适合使用 module 机制。

• 当你大量使用本地第三方包的时候，不太适合使用 module 机制。

因为 module 模式使用本地第三方包必须编辑 go.mod ，用 replace 命令指向本地包目录。

因为网络原因，在我们国内使用 module 机制有时候并不太方便，当我们要使用来自 golang.org 这类被屏蔽的网站的包时，我们一般必须通过其他方式下载到本地，然后编辑 go.mod 用 replace 命令指向本地目录，这样还不如就用 vendor 方式方便，除非你有特殊原因，必须在 GOPATH 之外保存源代码。在上面这种情况下，我推荐把下载的第三方包存放在 vendor 目录中，这样就可以兼容 非module 模式。

当使用本地的私有第三方包时，还是 vendor 模式比较方便，因为 module 模式使用本地第三方包必须编辑 go.mod ，用 replace 命令使用本地包。

end