这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
一、本堂课重点内容：
- 依赖管理
二、详细知识点介绍：
- 依赖管理
2.1.2 Go Vendor
通过在项目目录下增加vendor文件，所有依赖包的副本形式放在$ProjectRoot/vendor。
寻址优先级：vendor>GOPATH
通过每个项目引入一份依赖的副本，解决了多个项目需要同一个package依赖的冲突问题。
下面举一个Go Vendor的反例。
在上图中，Project A依赖于Project B与Project C，而Project B与Project C依赖于Package D的两个不同版本，且两个版本互不兼容，这种情况下就会再次出现依赖冲突的问题。
Go Vendor的问题：
- 无法控制依赖的版本
- 更新项目可能出现依赖冲突，导致编译出错。
归根结底是因为Go Vendor依然依赖于项目源码，而没有清晰地标识出版本的概念。
2.1.3 Go Module Go Module解决了同一个Project无法依赖同一个Package的多个版本的问题。
Go Module在Golang 1.11版本中实验性引入，1.16版本默认开启。
特点：
- 通过go.mod文件管理依赖包版本
- 通过go get/go mod指令工具管理依赖包
Go module实现了我们的终极目标：定义版本规则和管理项目依赖关系。
2.2 依赖管理三要素
①配置文件——go.mod
②中心仓库管理依赖库——Proxy
③本地工具——go get/mod
2.3.1 依赖配置——go.mod
依赖标识：[Module Path][Version/Pseudo-version]
2.3.2 依赖配置——version
语义化版本：
{MINOR}.${PATCH}
v1.3.0
V2.3.0
MAJOR：大版本，可以认为不同MAJOR的版本之间互不兼容。
MINOR：小版本，一般用于新增函数或功能，在同MAJOR下相互兼容。
PATCH：补丁，做代码bug的修复。
基于commit的伪版本：
vx.0.0-yyyymmddhhmmss-abcdefgh1234
v0.0.0-20220401081311-c38fb59326b7
v1.0.0-20201130134442-10cb98267c6c
第一部分与语义化版本相同。
第二部分为提交commit时的时间戳。
第三部分为12位的哈希码。
每次提交commit时go都会自动生成一个伪版本号。
2.3.3 依赖配置——indirect
indirect关键字：间接依赖
例：A->B->C
直接依赖：A->B
间接依赖：A->C
2.3.4 依赖配置——incompatible
incompatible关键字：
- MAJOR版本2及以上的模块会在模块路径增加/vN的后缀。
- 对于没有go.mod文件且MAJOR版本2及以上的模块，会标记+incompatible关键字。
例题：
三、引用参考：
