## module机制和dep/govendor机制是否冲突？
自从go团队推出`module`机制后，go团队和dep社区发生了一些冲突，有一篇有名的争论[《关于Go Module的争吵》](https://studygolang.com/articles/14130)，
读后给人一种错觉，似乎`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`命令使用本地包。
>[初窥Go module](https://tonybai.com/2018/07/15/hello-go-module/)
>
>[关于Go Module的争吵](https://studygolang.com/articles/14130)
*end*
有疑问加站长微信联系（非本文作者））
