# 1️⃣ GOPATH是什么
我们先看看第一个问题,GOPATH 是什么,我们可以输入如下命令查看:
$ go env
set GOPATH=D:\go
....
2
3
我们输入go env
命令行后可以查看到 GOPATH 变量的结果,我们进入到该目录下进行查看,如下:
go
├── bin
├── pkg
└── src
├── github.com
├── golang.org
├── google.golang.org
├── gopkg.in
...
2
3
4
5
6
7
8
9
GOPATH目录下一共包含了三个子目录,分别是:
- bin:存储所编译生成的二进制文件。
- pkg:存储预编译的目标文件,以加快程序的后续编译速度。
- src:存储所有
.go
文件或源代码。在编写 Go 应用程序,程序包和库时,一般会以$GOPATH/src/github.com/foo/bar
的路径进行存放。
因此在使用 GOPATH 模式下,我们需要将应用代码存放在固定的$GOPATH/src
目录下,并且如果执行go get
来拉取外部依赖会自动下载并安装到$GOPATH
目录下。
# 2️⃣ 为什么弃用 GOPATH 模式
在 GOPATH 的 $GOPATH/src
下进行 .go
文件或源代码的存储,我们可以称其为 GOPATH 的模式,这个模式,看起来好像没有什么问题,那么为什么我们要弃用呢,参见如下原因:
- GOPATH 模式下没有版本控制的概念,具有致命的缺陷,至少会造成以下问题:
- 在执行
go get
的时候,你无法传达任何的版本信息的期望,也就是说你也无法知道自己当前更新的是哪一个版本,也无法通过指定来拉取自己所期望的具体版本。 - 在运行 Go 应用程序的时候,你无法保证其它人与你所期望依赖的第三方库是相同的版本,也就是说在项目依赖库的管理上,你无法保证所有人的依赖版本都一致。
- 你没办法处理 v1、v2、v3 等等不同版本的引用问题,因为 GOPATH 模式下的导入路径都是一样的,都是
github.com/foo/bar
。 - Go 语言官方从 Go1.11 起开始推进 Go modules(前身vgo),Go1.13 起不再推荐使用 GOPATH 的使用模式,Go modules 也渐趋稳定,因此新项目也没有必要继续使用GOPATH模式。
# 3️⃣ 在 GOPATH 模式下的产物
Go1 在 2012 年 03 月 28 日发布,而 Go1.11 是在 2018 年 08 月 25 日才正式发布(数据来源:GitHub Tag),在这个空档的时间内,并没有 Go modules 这一个东西,最早期可能还好说,因为刚发布,用的人不多,所以没有明显暴露,但是后期 Go 语言使用的人越来越多了,那怎么办?
这时候社区中逐渐的涌现出了大量的依赖解决方案,百花齐放,让人难以挑选,其中包括我们所熟知的 vendor 目录的模式,以及曾经一度被认为是“官宣”的 dep 的这类依赖管理工具。
但为什么 dep 没有正在成为官宣呢,其实是因为随着 Russ Cox 与 Go 团队中的其他成员不断深入地讨论,发现 dep 的一些细节似乎越来越不适合 Go,因此官方采取了另起 proposal 的方式来推进,其方案的结果一开始先是释出 vgo(Go modules 的前身,知道即可,不需要深入了解),最终演变为我们现在所见到的 Go modules,也在 Go1.11 正式进入了 Go 的工具链。
因此与其说是 “在 GOPATH 模式下的产物”,不如说是历史为当前提供了重要的教训,因此出现了 Go modules。