go.sum冲突不是版本冲突，而是内容校验失败的明确信号；它表明同一模块版本在不同分支中记录了不同哈希值，违反Go安全机制，必须人工确认来源可信性后通过clean缓存、固定GOPROXY、重新download生成一致go.sum。
go.sum 冲突不是版本冲突，而是内容校验失败的明确信号——它意味着你本地下载的模块内容与之前记录的哈希不一致，必须人工确认是否可信。
为什么 go.sum 会“冲突”而不是自动合并
git merge 时出现 go.sum 冲突，常见于多人同时拉入不同依赖、切换代理源、或某人手改过 go.sum。但要注意：go.sum 不是锁文件，没有“版本优先级”概念；它的每一行都是独立校验项，冲突行代表同一模块版本在两分支中对应了不同哈希值——这本身就不合法。
- 哈希不一致 ≠ 网络抖动，而是内容真实不同（比如镜像源滞后、tag 被 force-push、本地 replace 指向了未提交的本地路径）
- Git 认为这是文本冲突，但 Go 工具链认为这是安全红线：
go build遇到不匹配直接报checksum mismatch，不给你运行机会 - 不能靠 git checkout --ours/--theirs 解决，因为任选其一都可能让校验失效
快速修复 go.sum 冲突的实操步骤
别手动删行、别复制粘贴哈希、别信“重生成就行”。目标是让所有校验和回归权威一致状态：
- 先执行
go clean -modcache清掉本地可能污染的模块缓存 - 确认 GOPROXY 设置合理（如
GOPROXY=https://proxy.golang.org,direct），避免国内镜像源因同步延迟导致哈希错位 - 检查
go.mod中是否有replace指向本地路径（如./fix）——这种情况下go.sum记的是你本地文件哈希，换机器必崩，应临时注释掉再操作 - 运行
go mod download，让 Go 重新拉取所有依赖并生成全新go.sum（注意：不是go mod tidy，后者只补缺不强制重算） - 对比新
go.sum和冲突前的 diff，确认只有预期变更（如新增模块、版本升级），没有大面积哈希漂移
什么时候该接受某个分支的 go.sum 行
极少数情况可以信任某一方的哈希值，但必须满足以下全部条件：
- 冲突模块是私有仓库，且已配置
GOPRIVATE=*.your-company.com，排除了公共校验服务器干扰 - 双方
go.mod中该模块的版本声明完全一致（包括伪版本时间戳和 commit hash） - 你亲自用
curl -L https://sum.golang.org/lookup/github.com/user/repo@v1.2.3查过官方校验库返回的哈希，与其中一方匹配 - 另一方的哈希来自被篡改的代理或本地 patch，且你已确认其不可信
CI/CD 中必须守住的底线
任何自动化流程里，go.sum 被修改都应触发显式告警，而非静默接受：
- 流水线第一步加
git status --porcelain go.sum，非空则 fail 并打印 diff —— 防止意外引入不一致 - 禁止在 CI 中执行
go mod tidy后自动 commitgo.sum，这等于绕过人工审查 - 构建命令必须包含
go mod verify，它会离线比对所有go.sum条目是否仍有效（不联网，纯本地校验） - 如果项目用了
go mod vendor，仍要保留go.sum并提交 ——vendor/目录不参与哈希计算，它只是分发手段，不是校验替代品
真正难处理的从来不是冲突本身，而是冲突背后那个没被问出口的问题：“这个哈希变更是谁触发的？为什么？”——每次 go.sum 变动，都应该能追溯到一次明确的 go get、go mod tidy 或 go mod download 操作，而不是靠 merge 解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
