这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
01. 依赖管理
了解 Go 语言依赖管理的演进路线
背景：
工程项目不可能基于标准库 0~1 编码搭建
管理依赖库
1.1 Go 依赖管理演进
- 不同环境（项目）依赖的版本不同
- 控制依赖库的版本
1.1.1 GOPATH
- 环境变量 $GOPATH
- 项目代码直接依赖 src 下的代码
- go get 下载最新版本的包到 src 目录下
GOPATH 弊端
1. 场景：A 和 B 依赖于某一 package 的不同版本
2. 问题：无法实现 package 的多版本控制
1.1.2 Go Vendor
- 项目目录增加 vendor 文件，所有依赖包副本形式放在 $ProjectRoot/vensor
- 依赖寻址方式：vendor => GOPATH
通过每个项目引入一份依赖的副本，解决了多个项目需要同一个 package 依赖的冲突问题
Go Vendor 弊端
问题：
1. 无法控制依赖的版本
2. 更新项目有可能出现依赖冲突，导致编译出错
1.1.3 Go Module
- 通过 go.mod 文件管理依赖包版本
- 通过 go get/go mod 指令工具管理依赖包
终极目标：定义版本规则和管理项目依赖关系
1.2 依赖管理三要素
1. 配置文件，描述依赖 go.mod
2. 中心仓库管理依赖库 Proxy
3. 本地工具 go get/go mod
1.2.1 依赖管理 —— go.mod
依赖标识：[Module Path][Version/Pseudo-version]
1.2.2 依赖配置 —— version
-
语义化版本
${MAJOR}.${MINOR}.${PATCH} -
基于commit 伪版本
vX.0.0-yyyymmddhhmmss-abcdefgh1234
1.2.3 依赖配置 —— indirect
A -> B -> C :
· A -> B 直接依赖
· A -> C 间接依赖
1.2.4 依赖配置 —— incompatible
-
主版本 2 + 模块会在模块路径增加/vN 后缀
-
对于没有 go.mod 文件并且主版本 2 + 的依赖，会 + incompatible
-
测试题目
1.2.5 依赖分发
回源
- 无法保证构建稳定性：增加/修改/删除软件版本
- 无法保证依赖可用性：删除软件
- 增加第三方压力：代码托管平台负载问题
Proxy
变量 GOPROXY
GOPROXY = "proxy1.cn, proxy2.cn, direct"
服务站点 URL 列表，"direct"表示源站
1.2.6 工具 —— go get
1.2.7 工具 —— go mod
小结：
Go 依赖管理演进
Go Module 依赖管理方案
总结
依赖管理（Dependency Management）是指对我们无法控制的库、包和依赖所组成的依赖关系网络进行管理。 依赖管理被认为是软件工程中最不被理解和最具挑战性的问题之一。依赖管理中的所有问题都会由于规模的增大变得更加复杂，因为我们意识到我们实际上并不是在讨论单个依赖项导入，而且在一般情况下，我们依赖于整个外部依赖网络。
