第 17 章模块与依赖 on Go 语言原本

17.1 依赖管理的难点

Mon, 01 Jan 0001 00:00:00 +0000

17.1 依赖管理的难点

现代软件几乎不再从零写起。一个寻常的服务端程序，import 列表往下走一层是日志库、HTTP 路由、序列化器，再往下是它们各自依赖的加密、压缩、网络原语,真正属于你自己的代码，可能不到整张依赖图的百分之一。这带来了复用的红利，也带来了一个本不属于你、却必须由你回答的问题： 这张图上每个包，到底该用哪个版本？ 这一节不急着给 Go 的答案，先把问题本身的难讲清楚。难点有两条主线：一是版本如何选（钻石依赖与约束求解），二是选定之后如何不漂移 （可重现构建）。理解了这两条，才能看懂 17.3 那套「最小版本选择」为什么值得专门设计，以及 Go 为走到那一步付出过什么代价。

17.1.1 钻石依赖：一个约束求解问题

依赖管理的核心难题，集中体现在一种叫钻石依赖（diamond dependency）的拓扑上。你的程序同时依赖 A 和 B，而 A 和 B 又都依赖同一个 C,依赖图从顶点出发分成两支，又在 C 处重新汇合，画出来正是一颗钻石。问题出在两支对 C 提出了不同的版本要求：

flowchart TD
 APP["你的程序 main"] --> A["A v1.0"]
 APP --> B["B v1.0"]
 A -->|"require C v1.2"| C12["C v1.2"]
 B -->|"require C v1.5"| C15["C v1.5"]
 C12 -.->|"二者只能合一"| PICK{"链进哪个 C?"}
 C15 -.-> PICK

为什么不能让 A 用 C v1.2、B 用 C v1.5，各取所需？多数语言做不到。C 的两个版本通常导出同一个包路径、同一组类型名，把两份链进同一个程序，链接器会撞上重复符号；即便链接器允许，C v1.2 的 Token 和 C v1.5 的 Token 在类型系统里也是两个互不兼容的类型,一旦 A 把自己拿到的 Token 传给 B，就会在边界上炸开。这条裂缝用一段示意代码看得更清楚：

17.2 语义化版本管理

Mon, 01 Jan 0001 00:00:00 +0000

17.2 语义化版本管理

要管理版本，先得让版本号有意义。17.1 把依赖管理的难处归到两点：钻石依赖里的版本冲突，与跨机器、跨时间的可重现构建。这两点能不能解，取决于一个更底层的前提，一个版本号到底承诺了什么。如果 v1.5 与 v1.4 之间的关系完全无从预料，那么任何选择算法都无从下手，只能退回到「把所有版本两两试一遍」的求解。Go 模块的做法，是先把版本号变成一份可被机器信任的契约，再在这份契约之上提出一条独特而强硬的规则,语义化导入版本。这一节讲清这两者，它们是 17.3 那套版本选择算法能够成立、且能简单到「一遍图遍历」的前提。

17.2.1 语义化版本：把兼容性写进数字

语义化版本（Semantic Versioning，semver）由 Tom Preston-Werner 在 2013 年定形为 2.0.0 规范，Go 模块直接采用了它，并在版本号前统一冠以 v。版本号形如 vMAJOR.MINOR.PATCH （如 v1.4.2），三段都是非负整数，且每一段的递增都有规范约定的含义：

PATCH（补丁）递增：「只引入向后兼容的 bug 修复」。v1.4.1 → v1.4.2，行为不变，只是更正了错误。
MINOR（次版本）递增：「以向后兼容的方式向公开 API 增加了功能」。v1.4 → v1.5，老代码原封不动仍能编译、仍能运行，只是多了可用的东西。
MAJOR（主版本）递增：「引入了向后不兼容的 API 变更」。v1.x → v2.0，老代码可能编译不过，或行为悄然改变。

把这套约定落到一个具体改动上，递增哪一段是被改动的性质唯一决定的，并无自由裁量：

1
2
3
4


现有版本 v1.4.2，下一次发布该打什么版本号？
 修了一个 panic，不动任何签名 → v1.4.3 （PATCH：兼容的修复）
 新增一个导出函数 Encode，旧 API 不变 → v1.5.0 （MINOR：兼容的新功能）
 删掉 Decode、或改了它的参数类型 → v2.0.0 （MAJOR：破坏兼容）

注意每升一段，更低的段都归零：v1.4.2 的次版本一升就是 v1.5.0 而非 v1.5.2，主版本一升就是 v2.0.0。这条归零规则保证了「同一主版本下，版本号越大、含的兼容功能越全」，17.3 的「取最大」才有明确语义。

17.3 最小版本选择算法

Mon, 01 Jan 0001 00:00:00 +0000

17.3 最小版本选择算法

确定了语义化版本（17.2）后，还剩最后一问：当依赖图里各模块要求同一个依赖的不同版本时，到底选哪个版本？Go 的答案是一个反直觉、却异常简洁的算法,最小版本选择 （Minimal Version Selection, MVS）。它是 Go 模块最具特色、也最值得玩味的设计：别家包管理器把这件事做成了一个需要约束求解器的难题，Go 却把它压成了一遍图遍历。本节先把规则讲清，再看它为何能这么简单，最后把它放回整个领域的谱系里，看清它究竟换走了什么、换来了什么。

17.3.1 选「满足要求的最低版本」

MVS 的规则简单到令人意外：对每个依赖，选所有要求中最高的那个最低要求,换句话说，选择 能满足所有模块要求的最低版本。先用本书一贯的小例子建立直觉。你的程序直接要求 C ≥ v1.2; 依赖 A 要求 C ≥ v1.3;依赖 B 要求 C ≥ v1.1。三个要求里最高的下限是 v1.3,MVS 就选 C v1.3。注意这里的关键：哪怕此刻 C 已经发布了 v1.9，MVS 也不选 v1.9,它只选「满足所有要求的最低版本」，即 v1.3。

把这条规则放进一张真实的依赖图，就是 Go 官方文档采用的例子。主模块要求 A ≥ v1.2、B ≥ v1.2; A v1.2 要求 C ≥ v1.3;B v1.2 要求 C ≥ v1.4;而 C v1.3 与 C v1.4 都要求 D ≥ v1.2。MVS 从主模块出发，沿 require 边走遍整张图，为每个模块记下「见过的最高要求」：

17.4 vgo 与 dep 之争

Mon, 01 Jan 0001 00:00:00 +0000

17.4 vgo 与 dep 之争

今天的 Go 模块（Go Modules）并非一开始就有。它从一场颇具戏剧性、也颇有争议的社区事件里诞生：vgo 与 dep 之争。这段历史不只是八卦，它折射出开源项目治理、技术决策与社区情绪之间的真实张力，是理解 Go 模块「为何是今天这样」的最后一块拼图，也是这本书一路谈下来的设计哲学在工具链层面的一次集中演出。

前面两节已经把 Go 模块的技术内核摆出来了：语义化版本管理（17.2）把主版本写进导入路径，最小版本选择（17.3）用一条确定性算法挑出每个依赖的版本，二者合起来，让 Go 既不需要 lock 文件、也不需要约束求解器。这一节回答的是另一个问题：为什么是这套方案，而不是当时社区已经投入两年、几乎被默认为「未来」的那一套。要讲清楚这个，得把时间拨回到 2016 年。

17.4.1 dep：社区的「官方实验」

GOPATH 时代的依赖混乱（17.1）催生过一大批第三方工具：godep、glide、 govendor，各自为政，互不兼容。2016 年，Go 团队决定收口，成立了一个依赖管理工作组，由 Sam Boyer 等社区成员牵头，做出一个被定位为官方实验（official experiment）的工具： dep。它不是某个人的玩具，而是 Go 团队背书、社区深度参与、被广泛理解为「将来会并入 go 命令」的候选方案。许多公司和个人据此调整了工程实践，把项目迁到 dep 上。

技术上，dep 走的是当时主流的路子，与 Rust 的 Cargo、Ruby 的 Bundler、JavaScript 的 npm 一脉相承：一个清单文件声明你想要的版本范围，一个 lock 文件钉死本次解析出的精确版本，中间夹着一个约束求解器。求解器要做的事，本质是布尔可满足性（SAT）：把「A 需要 B 的 >=1.2」「C 需要 B 的 <2.0」这类约束翻译成逻辑公式，搜一组同时满足所有人的版本赋值出来。

第 17 章 模块与依赖 on Go 语言原本

17.1 依赖管理的难点

17.1 依赖管理的难点

17.1.1 钻石依赖：一个约束求解问题

17.2 语义化版本管理

17.2 语义化版本管理

17.2.1 语义化版本：把兼容性写进数字

17.3 最小版本选择算法

17.3 最小版本选择算法

17.3.1 选「满足要求的最低版本」

17.4 vgo 与 dep 之争

17.4 vgo 与 dep 之争

17.4.1 dep：社区的「官方实验」

第 17 章模块与依赖 on Go 语言原本