go.sum文件用于校验依赖内容完整性而非锁定版本；它通过比对模块zip包及go.mod文件的哈希值，确保每次构建使用完全相同的依赖代码。

go.sum 文件的作用不是锁定版本，而是校验依赖内容是否被篡改——它确保你这次下载的 github.com/gorilla/mux@v1.8.0，和上次成功构建时用的那个“一模一样”。

为什么 go.sum 会报 checksum mismatch？

这是 go.sum 在尽职工作：它发现当前下载的模块 zip 包哈希值，和 go.sum 里记录的不一致。常见原因包括：

• 模块作者在未改版本号的前提下偷偷发布了新代码（比如打了个 hotfix patch 但没升版）
• 你用了不稳定的代理（如自建 GOPROXY），返回了被污染或缓存错乱的包
• 本地手动修改过某个依赖的源码，又没清理缓存就重新 build
• 私有模块未配置 GOPRIVATE，导致 Go 尝试向官方校验服务器（sum.golang.org）查询，而该服务器无法验证你的私有域名

此时 Go 会中止构建，并抛出类似错误：

verifying github.com/sirupsen/logrus@v1.9.3: checksum mismatch
    downloaded: h1:7jgDy12zZBQXVJxY6m8oE4FfGkL5QcKqZ+UdOzKqZ+U=
    go.sum:     h1:5a5e6b1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a=

go.sum 怎么生成和更新？

你几乎不需要手动生成或编辑它——Go 工具链会在以下操作中自动维护：

• go mod tidy：拉取缺失依赖、清理未使用项，并同步更新 go.sum
• go build 或 go test：首次运行时若 go.sum 缺失，会自动创建；后续运行则强制校验
• go get：添加/升级依赖后，自动追加对应模块的两个哈希（h1: 和 go.mod 行）

注意：go.sum 中每个模块通常有两行，例如：

github.com/gorilla/mux v1.8.0 h1:...long-sha256-hash...
github.com/gorilla/mux v1.8.0/go.mod h1:...another-hash-for-its-go.mod...

前者校验模块源码压缩包，后者校验它的 go.mod 文件——这对间接依赖尤其关键。

必须提交 go.sum 到 Git 吗？

必须。不提交 = 放弃可重现构建。

• CI 流水线拉代码后若无 go.sum，会按当前网络环境重新下载依赖，可能拿到已被覆盖的“新版同名包”
• 团队成员之间 go.sum 不一致，会导致本地能跑、CI 报错，或不同人构建出二进制行为不一致
• .gitignore 里删掉 /go.sum 是高危操作，等同于主动绕过 Go 的完整性防护

例外情况极少：仅当你明确使用 go mod vendor 并完全离线构建时，可考虑不依赖 go.sum，但代价是体积膨胀和 vendor 更新繁琐。

容易被忽略的关键点

go.sum 不防恶意初始依赖——它只保证“和上次一样”。如果你第一次引入的 github.com/xxx/badlib@v0.1.0 就带后门，go.sum 会忠实地锁住这个后门的哈希值，并在每次构建时坚定地帮你加载它。

真正需要你主动做的是：go list -m all 审计依赖树、govulncheck ./... 扫描已知漏洞、定期 go mod tidy -v 观察是否有意外升级、对关键第三方库做人工代码抽查。