GO MODULE 总结

这里的 markdown 用着是真不习惯

Go 安装、升级、版本替换

安装 brew
https://brew.sh/

安装 go
brew install go

升级 go
brew upgrade go

版本替换（比如我团队用的是 go1.17，不过我安装的是 1.19，那么需要 go 降级回去）

# 安装 1.17
brew install [email protected]

# 取消 link 现在 1.19 版本的 go
brew unlink go

# 强制 link 1.17 版本的 go
brew link --force [email protected]

# go version 查看是否替换成功

Go 包管理迭代历程

（摘自文章：https://www.modb.pro/db/211633）
复用代码一直是软件开发中提升效率的重要方法，大型工程的开发离不开积累的各种开源、闭源的依赖库. go 语言也不例外，go 的包管理随 go 的诞生后，经过了一系列的迭代. 迭代历程如下:

1. 2012年3月 Go 1 发布，此时没有版本的概念
2. 2013年 Golang 团队在 FAQ 中提议开发者保证相同 import path 的兼容性，后来成为一纸空文
3. 2013年10月 Godep
4. 2014年7月 glide
5. 2014年 有人提出 external packages 的概念，在项目的目录下增加一个 vendor 目录来存放外部的包
6. 2015年8月 Go 1.5 实验性质加入 vendor 机制
7. 2015年 有人提出了采用语义化版本的草案
8. 2016年2月 Go 1.6 vendor 机制 默认开启
9. 2016年5月 Go 团队的 Peter Bourgon 建立委员会，讨论依赖管理工具，也就是后面的 dep
10. 2016年8月 Go 1.7: vendor 目录永远启用
11. 2017年1月 Go 团队发布 Dep，作为准官方试验
12. 2018年8月 Go 1.11发布 Modules 作为官方试验
13. 2019年2月 Go 1.12发布 Modules 默认为 auto
14. 2019年9月 Go 1.13 版本默认开启 Go Mod 模式

Go 包管理模式

GOPATH 模式

早期 go 使用的是 GOPATH 模式，GOPATH 内存在三个文件夹：

1. bin：存放可执行的二进制文件，当我们把 $GOPATH/bin 配置在环境变了 PATH 中后，可以在全局位置使用bin 中的可执行文件
2. pkg：存储编译的中间产物 .a
3. src：存储源码
   GOPATH 模式下所有的项目以及依赖的包都需要存放在 $GOPATH/src 中，项目依赖包会在 $GOPATH/src 或者 $GOROOT/src 中查找

GOPATH 模式存在的版本管理问题：

所有的项目以及它们依赖的包都存放在 $GOPATH/src，并且依赖包之间没有版本的概念，所有的项目依赖同一个包，当某个项目的依赖包需要升级时，那么就是全局升级，其他依赖该包的项目在下次编译的时候都会使用新版本的依赖包，这可能导致其他项目出现不兼容问题

Vendor 模式

Go 1.5 版本添加了 vendor 模式，每个项目都有单独的一个 vendor 目录，该目录下存储项目的依赖包
这使得多个项目之间的依赖包隔离，不会有全局升级的风险
由于 vendor 目录在项目目录下，打包的时候可以直接将项目的所有依赖包 vendor 目录和源代码一起打包，但多个项目的话会存在大量重复的依赖包

Vendor 模式依赖包的查找顺序：
1.查找当前项目的 vendor 目录
2.查找上一目录的 vendor 目录
3.一层层往上，直到 $GOPATH/src/vendor，都没有就报错