go.sum冲突本质是模块内容哈希不一致，而非版本问题；它由多人执行go mod tidy/get、缓存/代理差异、间接依赖变动或CI校验策略不一导致，须通过删除go.sum后运行go mod download和go mod tidy重建，严禁手动编辑或单边接受。
go.sum 冲突不是版本问题，而是校验不一致的明确信号——必须同步处理，不能随便删或忽略。
为什么 go.sum 会频繁在 Git 中产生冲突
go.sum 不是“可选配置”，它是每个依赖模块内容哈希的精确快照。当多人同时执行 go mod tidy、go get 或拉取不同 commit 的依赖时，哪怕只有一行哈希值变化，Git 就会标记为冲突。
常见诱因包括：
- 某人本地缓存了旧版模块，
go mod tidy下载的是旧哈希；另一人网络走代理，下载到新版哈希 - 某依赖的间接依赖（
require ... // indirect）被自动升级，但未显式声明，导致go.sum新增/修改多行 - 有人手动编辑了
go.mod但没运行go mod tidy，go.sum缺失对应条目 - CI 环境使用了
GONOSUMDB或跳过校验，而本地没有，造成哈希记录不一致
如何安全解决已发生的 go.sum 冲突
不要直接接受某一方的版本，也不要手工删行。正确做法是让 Go 工具链重新生成权威一致的 go.sum：
- 先确保
go.mod冲突已手动合并完成（保留所有require行，无重复、无遗漏） - 删除当前
go.sum文件（或清空内容） - 运行
go mod download—— 强制拉取go.mod中声明的所有模块（含间接依赖） - 再运行
go mod tidy -v—— 它会重建go.sum，并输出新增/变更的模块路径和哈希 - 检查输出中是否包含可疑的
// indirect模块，必要时用go mod graph | grep追溯来源
如果某模块反复出现哈希不一致，大概率是其发布方重打了 tag（tag retraction），此时应联系该库维护者，或临时用 replace 锁定已验证的 commit。
预防 go.sum 冲突的团队协作习惯
冲突本质是流程断点。真正有效的预防不在工具，而在约定：
- 所有成员必须提交
go.mod和go.sum—— 缺一不可，CI 流水线需加go mod verify校验 - 禁止直接修改
go.sum；所有变更必须通过go get或go mod tidy触发 - 升级依赖时，统一用
go get example.com/lib@v1.2.3显式指定版本，避免go get -u引入不可控的间接依赖升级 - 在
.gitattributes中添加go.sum merge=union可缓解简单冲突，但不能替代上述流程
最常被忽略的一点：go.sum 的每一行都绑定具体模块路径+版本+哈希，它不关心“谁改的”，只认“内容是否匹配”。所以只要团队共用同一套 go.mod 和相同的 Go 版本、代理策略，go.sum 就天然可重现——前提是没人绕过工具链直接手改。
