go.sum冲突本质是模块哈希值不一致，需通过go mod verify验证内容真实性，而非简单合并文本；必须清空缓存后由go mod tidy自动重建，确保依赖字节级一致且可重现。
go.sum 文件冲突不能靠“选左边或右边”简单解决，必须验证模块内容一致性，否则会引入供应链风险。
go.sum 冲突本质是哈希值不一致，不是文本行冲突
当 go.mod 变更触发 go mod tidy 时，不同环境或提交时间可能生成不同 go.sum 行：同一模块路径+版本，但 h1:xxx 校验和不同。这不是 Git 合并逻辑能判断的“哪边对”，而是说明：要么某方缓存损坏、要么代理篡改、要么模块作者重发了同版本 tag（极危险）。直接接受任一版本都可能让构建结果不可重现。
- 常见错误现象：
go build在 CI 失败但本地成功 →go.sum中某行哈希不匹配，go工具拒绝加载该模块 - Git 冲突标记如
<<<< HEAD出现在go.sum里，只是表象；真正要问的是“哪一行对应的模块内容真实可信” - 不能用
git checkout --ours go.sum强制保留本地——你本地缓存可能已污染
用 go mod verify 精准定位哪个模块哈希失效
go mod verify 不依赖 go.sum 文件，而是直接从 GOPROXY 下载模块源码压缩包，重新计算校验和。它能告诉你哪些模块的当前缓存与官方哈希不符。
- 运行
go mod verify，输出类似github.com/sirupsen/logrus v1.9.0: checksum mismatch→ 立刻锁定问题模块 - 若输出
all modules verified，说明冲突是误报（比如某人手改了go.sum），可安全删掉冲突标记，保留任一版 - 注意：该命令默认走 GOPROXY；若公司内网禁用代理，需先设
export GOPROXY=direct，再用go mod download -x观察实际拉取源
自动化修复：go mod tidy + go mod download 组合清理
手动删 go.sum 或编辑哈希值极易出错。正确做法是清空缓存后由工具重建：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 删掉
go.sum全部内容（保留文件存在），运行go mod tidy -v→ 它会重新下载所有依赖并生成新go.sum - 更稳妥：先
go clean -modcache清空整个模块缓存，再go mod tidy，避免旧缓存干扰 - CI 流程中应固定 GOPROXY 和 Go 版本，例如
GOPROXY=https://proxy.golang.org,direct，防止不同代理返回不同压缩包 - 如果项目依赖私有模块，确保
GOPRIVATE=*.your-company.com已设置，否则go mod tidy会跳过校验直接拉取
合并 PR 时预防 go.sum 冲突的实操习惯
多人协作中 go.sum 冲突高频发生，根本原因是不同人执行 go mod tidy 的时机和环境不一致。
- 禁止在 PR 中单独提交
go.sum修改——它必须和go.mod变更成对出现 - CI 流水线第一步跑
go mod tidy -compat=1.21（按项目 Go 版本锁死），失败则拒收 PR - 开发者本地提交前，统一执行：
go mod tidy && git add go.mod go.sum，避免只提go.mod - 不要把
go.sum加进 .gitignore —— 它是锁定机制的一部分，缺失等于放弃依赖安全
最麻烦的不是冲突本身，而是有人把 go.sum 当普通配置文件去“合并”，却忘了它背后是密码学哈希——差一个字节，整个模块就不可信。每次修复，都要回到 go mod verify 这一步验证，而不是看 Git 工具是否标记为“已解决”。
