在许多编程语言的生态中，开发者习惯了“清单文件（Manifest）”与“锁文件（Lockfile）”的二元对立（如 package.json 对比 package-lock.json，Cargo.toml 对比 Cargo.lock）。这种思维定式很容易让我们误以为 Go 中的 go.sum 就是那个负责锁定版本的 Lockfile。

“我需要大家停止查看go.sum，尤其是别用它来分析依赖图。它不是一个‘锁文件（lockfile）’，它对版本解析没有任何语义影响。实际上，你根本没有理由去解析它。”

—— Filippo Valsorda, 前 Go 安全团队负责人

这种在其他语言生态中形成的固定模式，常常让我们下意识地将 go.sum 归类为版本锁文件。然而，事实并非如此。

前 Go 安全团队负责人 Filippo Valsorda 在他最新的文章中大声疾呼：这是一个巨大的误解。

误解澄清：go.sum到底是什么？

简单来说，go.sum 只是 Go 模块校验和数据库的一个本地缓存。

它的内容：它是Go模块版本与其加密哈希值的映射表。它的作用：纯粹是为了安全。它确保你下载的某个模块版本无论来自哪里，其内容都与全球 Go 生态系统中其他人下载的内容完全一致。它的局限：它可能包含即使在构建中未被使用的模块版本的哈希；它不参与包的解析过程；它的存在与否甚至不影响构建的语义结果（最初设计时它甚至不是默认开启的！）。

如果你想分析项目的依赖关系、排查版本冲突，或者理解构建过程，请忽略go.sum。它给不了你想要的答案。

真相揭秘：go.mod才是真正的 MVP

在 Go 的设计中，go.mod 承担了其他语言中 Manifest 和 Lockfile 的双重角色，甚至更多。

它是清单 (Manifest)：列出了直接依赖。它是锁文件 (Lockfile)：它列出了所有依赖（直接和间接）的精确版本。自Go 1.17起，它包含了一个完整的依赖图剪枝，列出了构建主模块及其测试所需的所有传递依赖。语义化版本控制 (SemVer) 是默认假设，go.mod中列出的版本不仅是当前使用的版本，也是依赖图中所有模块的最小版本(mvs)要求。

Go 模块设计的优雅之处

Filippo 指出，Go 模块系统在简洁性上被大大低估了。与其他生态系统相比，Go 实现了令人惊叹的特性：

单一事实来源：一切都在一个人类可读的go.mod文件中。无“钻石依赖”地狱：Go 的最小版本选择 (MVS) 算法优雅地解决了依赖冲突。自动化管理：所有go命令都能自动维护go.mod。go mod tidy更是保持依赖整洁的神器。可预测性：不会意外引入一个你的下游用户还没有拥有的新特性；添加依赖时，也不会自动升级其所有传递依赖到最新版（从而引入潜在的不稳定因素）。

小结

下次当你想了解项目的依赖结构时，请直接查看go.mod。

或者，使用更专业的工具：

解析go.mod文件（使用golang.org/x/mod/modfile）。运行go mod edit -json 获取 JSON 格式。使用go list -m all查看最终的构建列表。

至于go.sum？就让它静静地呆在那里，做它该做的事——默默守护你的供应链安全，仅此而已。