Go go.sum 为什么总是被重新写入

如果每次执行 go mod tidy，go.sum 都出现变化，先不要把它当成“Go 随机重写文件”。更常见的原因是：本次命令加载了不同的包集合，工具链按不同的兼容版本维护校验，或者工作目录实际处在 go.work 边界内。把差异分类后，通常能找到稳定的修复点。

官方文档：https://go.dev/ref/mod#go-sum-files

先看变化内容，再判断是不是异常

go.sum 每行记录模块路径、版本和哈希；同一个模块既可能有压缩包校验，也可能有只针对 go.mod 的校验。Go 官方还明确说明，go mod tidy 会补齐缺失条目，也会删除当前模块图不再需要的条目。因此“文件被写入”本身不是故障，关键是变化是否可解释。

# 先保存当前差异，避免把 go.mod 的变化混进判断
git diff -- go.mod go.sum go.work go.work.sum

# 只计算 tidy 计划，不立即修改文件
go mod tidy -diff

# 查看当前模块图，确认依赖版本是否已经变化
go list -m all

如果只是新增某个模块的 /go.mod 校验，通常对应依赖图加载；如果大量旧条目被删除，常见原因是 tidy 重新计算了当前源码、测试和构建标签下的模块集合。若变化集中在 go.work.sum，则先检查是不是从工作区根目录运行了命令。

固定 Go 版本和模块入口

排查时要把“谁执行命令”固定下来。go.mod 中的 go 指令代表模块所需的最低 Go 版本；在较新的 Go 版本中，它还会影响模块图裁剪、间接依赖记录和 tidy 的兼容检查。团队成员如果分别用不同工具链，可能得到不同但各自合理的 go.sum。

# 记录命令、模块根目录和工作区状态
go version
go env GOMOD GOWORK GOFLAGS GOPROXY GOPRIVATE GONOSUMDB GOSUMDB

# 从模块根目录执行，避免把工作区文件当成项目文件
go env GOMOD

# 检查项目声明的 Go 版本；这里的路径按项目实际位置替换
sed -n '1,30p' go.mod

重点看三组差异：一是 GOWORK 是否从 off 变成了某个 go.work；二是 GOFLAGS 是否带了 -modfile 或其它模块参数；三是 CI 与本地的 Go 版本、源码分支和生成文件是否一致。没有先统一这些输入，反复运行 tidy 只会重复制造噪声。

用一次可解释的 tidy 收敛变更

确认入口和工具链后，先使用 -diff 阅读计划，再执行一次正式整理。不要把 go mod tidy 当成“只整理直接依赖”的命令：它会加载主模块包、工具和测试递归导入的包，还会考虑大多数构建标签，所以测试文件或平台文件的变化也可能带来新的校验行。

# 先预览 tidy 会修改什么；有差异时命令会返回非零退出码
go mod tidy -diff

# 确认预览内容属于本次源码和测试变更后，再正式整理
go mod tidy

# 把整理结果作为一个独立差异查看
git diff --stat -- go.mod go.sum
git diff -- go.mod go.sum

如果团队需要兼容比当前 go 指令更老的模块图，关注 go mod tidy -compat=版本 的选择；官方规则会让 tidy 默认检查紧邻的上一版本兼容性。这里的版本不是越新越好，而应与项目支持矩阵和 CI 一致。

私有依赖、替代文件和回滚边界

私有模块会改变校验路径。GOPRIVATE 会影响代理和校验数据库的使用；如果本地、CI 的配置不同，同一个依赖可能在一处新增校验，在另一处不新增。另一方面，使用 -modfile=custom.mod 时，Go 会配套使用由该文件名推导出的 custom.sum，这时你看到的并不是默认 go.sum。

# 只展示配置，不把私有凭据写入日志或文章
go env GOPRIVATE GONOPROXY GONOSUMDB GOSUMDB

# 显式指定替代模块文件时，注意它会使用对应的替代 sum 文件
go list -modfile=release.mod -m all

# 发现整理结果不属于当前变更时，先回退工作区文件，再修正环境
git restore -- go.mod go.sum

最后一条只适合尚未提交、且确认这些文件全部属于本次尝试的工作区。生产分支不要用回滚掩盖依赖变化：先保留差异，找到触发它的模块、工具链或环境变量，再决定是否提交。

快速结论：把“反复改写”变成四个检查点

• 新增校验：先确认是否下载了新的 .mod 或 .zip。
• 删除校验：检查源码、测试、构建标签和 go mod tidy 的兼容范围。
• 换文件：确认 GOWORK、-modfile 与工作目录。
• 换环境：统一 Go 版本、代理、私有模块配置和 CI 命令。

能用同一套输入连续得到相同差异，说明问题已经从“随机改写”变成了可审查的依赖变更。提交前保留 go.mod 与 go.sum 的成对 diff，后续升级或排障会容易很多。

相关问题

为什么只改了 go.mod，go.sum 也会变化？ 因为模块图或被读取的依赖元数据发生了变化，Go 需要补写对应的校验。

为什么本地没变化，CI 却改了 go.sum？ 优先比较 Go 版本、工作区入口、构建标签、GOFLAGS 以及 GOPRIVATE 等环境变量。

go.sum 可以直接删除吗？ 不建议把删除它当作修复手段；重新下载依赖时，Go 会重新计算并写回需要的校验，应该先解决输入不一致。