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
