爱站程序员基地前言
最近在看一些go语言相关的书，发现了一个有意思的事情：其中一本书最新印刷的版本是2017年3月，而golang包管理的后起之秀
go module
伴随go1.11于2018年8月诞生——因此，书里没有。
有感于golang发展速度之快，且当下项目中
go module
、
go vendor
（go1.5之后一个热门的包管理工具）交织，甚至时不时看到
go path
包管理模式在一些文章中死灰复燃，我想有必要正确梳理一下其中的缘由，以便大家选择合适的包管理模式。
白泽，无脑选择
go module
不好吗？过时的东西有必要学吗？
事实上，我认为你可以不用它，但是你得懂为什么这种技术不推荐甚至被弃用，而且你很难定义什么是过时的技术，比如我项目中就用到了vendor。很多golang学习者可能有其他语言的基础，上手go也很快，java有maven，那go必然也有xx包管理工具吧！打开搜索引擎输入go快速入门，安装与项目构建，有的人查到了
go path
，有的人查到了
govendor
、有的人则是
go module
。
这也是我想写一篇文章总结的原因（万一有一天go module也不推荐使用了呢！这种演变的思路值得了解），看过之后保证你能看懂别人文章中写的GOPATH/src、GOPATH/bin、GOPATH/pkg/mod云云，我们开始。
两个命令
go install xxx（下载xxx第三方二进制可执行文件 ）
go get xxx（下载xxx第三方依赖包）
下载可执行文件/第三方依赖到本地哪里？不同的包管理工具不同，下面讲。
两个路径
- GOROOT：go的安装目录，类似java的jdk，存放一些内置的开发包和工具。
- GOPATH：go指定的工作空间，用于保存go项目的代码和第三方依赖包。
# mac可以通过go env查看go相关的环境变量，windows类似go envGOROOT="/usr/local/go"GOPATH="/Users/baize/GolandProjects/"
三个包管理工具
go path【不推荐使用】
go path是最早的依赖包管理方式（Go1.0），启用GOPATH模式（注意区分GOPATH模式和GOPATH路径，这是两个语境），要求将所有工程代码要求放在
GOPATH/src
目录下。在工程经过
go build xxx
、
go install xxx
或
go get xxx
等指令后，会将拉取的第三方xxx依赖包放在
GOPATH/src
目录下，产生的二进制可执行文件放在
GOPATH/bin
目录下，生成的中间缓存文件会被保存在
GOPATH/pkg
下。
问题：GOPATH模式下没有版本控制的概念，在执行
go get
的时候，获取的永远是最新的依赖包，下载到
GOPATH/src
，如果你有两个工程依赖一个包的v1和v2版本，则会发生冲突，因为
GOPATH
模式下两个工程内依赖的导入路径都是一样的，因此两个工程获取的都是v2版本。
命令：显然
GOPATH
模式下
go get会将代码拉取到GOPATH/src
，这个模式已经不推荐使用了。
govendor【不推荐使用】
在 Go 1.5版本之后，Go 提供了
GO15VENDOREXPERIMENT
环境变量(Go 1.6版本默认开启该环境变量)和
Govendor
包管理工具，用于将
go build
时的应用路径搜索调整成为当前工程
/vendor
目录的方式，有效的解决了不同工程使用自己独立的依赖包目录。编译 Go 代码会优先从
vendor
目录先寻找依赖包，
vendor
目录如果没有找到，然后在
GOPATH
中查找，都没找到最后在
GOROOT
中查找。
优势：因为将第三方依赖完全和工程整合，使得项目构建速度快，且可以工作在无法连接外网的CI/CD流程中。
问题：放弃了依赖重用，使得冗余度上升
下载：go install github.com/kardianos/govendor（govendor是第三方可执行文件，下载可执行文件用go install，用go get也行，但是会有告警）。
命令：
govendor --help
查看所有命令（要先使用go get xxx将xxx依赖下载到$GOPATH/src中，此时go vendor包管理本质是基于GOPATH模式的）
| 命令 | 功能 |
|---|---|
| govendor init | 初始化
vendor 目录 |
| govendor add | 添加包到
vendor 目录（相关依赖则是从$GOPATH/src中获取） |
| govendor add +external | 添加所有外部包到
vendor 目录 |
| govendor get | 拉取依赖包
vendor 目录 |
然后我在govendor的代码库中看到了下面这段话：👇（这个README还是两年前更新的，而且这个库已经很久不维护了，嗯…）。
go module
从Go1.11开始，官方推出Go module作为包管理工具，且从Go1.13开始为默认选择启用。
GOMODULE
模式下所有依赖的包存放在
GOPATH/pkg/mod
目录下，所有第三方二进制可执行文件放在
GOPATH/bin
目录下，且工程项目可以放在
GOPATH
路径之外，但要求项目中需要有go.mod文件（该文件通过go mod init命令初始化可以得到）。
GOMODULE
模式和
GOPATH
模式一样都指定了依赖包存放的位置，而不是如vendor模式放入工程内，区别在于GOMODULE的
go.mod
文件中记录了所依赖包的具体版本，既实现了工程之间重用依赖包，且解决了
GOPATH
模式下不同工程无法依赖同一个包的不同版本的问题。
启用GOPATH模式要求工程目录在
GOPATH/src
之下，而要使用GO MODULE模式，需要先开启配置。在Go1.13之后，可以通过如下命令设置GO MODULE启用状态。
mac：（windows类似）
# 光开启也是不行的，需要配合go.mod才能工作，下面讲export GO111MODULE=onexport GO111MODULE=off# 当项目路径在 $GOPATH 目录外部时， 设置为 GO111MODULE = on 当项目路径位于 GOPATH 内部时，即使存在 go.mod, 设置为 GO111MODULE = offexport GO111MODULE=auto
go mod命令：go help mod查看相关帮助命令（govendor是第三方可执行文件，但是go mod命令是go自带的，不用额外go install）
| 命令 | 功能 |
|---|---|
| go mod init | 初始化当前文件夹，创建
go.mod 文件，事实上，如果你的环境中GO111MODULE=on，使用类似goland的工具创建工程会自动生成go.mod |
| go mod tidy | 包整理（多的删去、少的拉取），使用之前自然是import了需要的库了 |
| go mod vendor | 将依赖包复制到工程文件的
vendor 目录下 |
在
GO111MODULE=on
且项目中包含go.mod文件时，执行go get xxx 或 go install xxx下载的包或者二进制可执行文件将放入
GOPATH/pkg/mod
目录和
GOPATH/bin
目录下。
go mod vendor：
这里着重再提一下go mod vendor，刚刚还说govendor自己都不推荐用了，为什么
GOMODULE
模式还提供了这个关联go vendor功能的命令呢？
事实上，如果你需要使用vendor模式管理包，说明一定属于如下两种情况：
- 工作在
GOPATH
模式下，Go版本早于1.11或者GO111MODULE=off（因为这种方式依赖GOPATH模式，所以已经不推荐了）
- 工作在
GO MODULE
模式下，但是还是利用vendor管理依赖包，而go mod vendor就属于这种情况（算是保留了vendor一线生机，毕竟还是有使用场景的，且go mod vendor利用GOMODULE模式为基础，摒弃了GOPATH为基础的govendor）。
结束语
码字不易，三连才是真情～
刚建了个微信小群，欢迎加入一起唠嗑，一同备战秋招！
