go.mod 和 go.sum 冲突源于语义变更未对齐，而非时间戳问题；真正导致合并失败的是版本号、校验和或 replace 规则的实质性差异，需通过统一执行 go mod tidy 解决。
go.mod 和 go.sum 的冲突不是时间戳问题，而是语义变更未对齐
很多人看到 go.mod 文件里一堆 // indirect 或时间戳字段变化就以为是“时间戳冲突”，其实 go.mod 中的 // indirect 注释、// exclude、// require 行序、以及 go.sum 每行末尾的哈希长度（h1: vs go:）都由 go mod tidy 自动标准化。所谓“时间戳”只是 go.sum 里某些旧版 Go 工具写入的冗余注释（如 # explicit 后带毫秒时间），它不参与校验，也不影响构建——真正引发合并失败的，是模块版本号、校验和、或 replace 规则的实质性差异。
为什么 git merge 时 go.mod/go.sum 总报冲突？
常见触发场景：
- 两个分支各自执行了
go get github.com/some/pkg@v1.2.3，但拉取的是同一 commit 的不同 tag（比如 v1.2.3 和 v1.2.3-hotfix），导致go.mod中require版本不一致 - 分支 A 运行过
go mod tidy清理了未使用依赖，分支 B 没运行，导致go.mod中require行数/顺序不同 - 分支 A 添加了
replace覆盖本地调试包，分支 B 没有，合并时该行直接冲突 -
go.sum冲突常因某分支升级了间接依赖（如golang.org/x/net），而另一分支没更新，导致同一模块出现两套哈希值
merge 前必须统一执行 go mod tidy
这不是可选项，是协作前提。只要团队中有人跳过这步，合并就会变高概率冲突。正确做法：
- 所有功能分支开发完、提交前，先在干净工作区执行：
go mod tidy -v（-v可看到增删了哪些依赖） - 确认输出无
find错误、无missing提示，且go.mod和go.sum都被修改并暂存 - 若提示
require ...: version "..." missing，说明本地 GOPROXY 不稳定，应临时设为GOPROXY=https://goproxy.cn,direct后重试 - 禁止手动编辑
go.mod中的require行——所有变更必须经go get或go mod tidy触发
解决已发生的 go.sum 冲突：不要手动删行
go.sum 是校验和数据库，每行对应一个模块+版本+哈希。手动删掉某行看似“解决冲突”，实则会导致后续 go build 失败（报 checksum mismatch）。正确做法：
- 保留冲突标记中的双方内容，先提交一个“脏”的
go.sum（即含/<code>>>>>） - 立即执行：
go mod graph | head -20查看当前依赖拓扑，确认哪几个模块版本存在分歧 - 运行：
go mod verify—— 它会列出所有校验失败的模块，精准定位问题源头 - 根据
go mod verify输出，用go get -u=patch或显式go get example.com/pkg@v1.5.2统一版本，再跑一次go mod tidy - 此时
go.sum会自动重写，冲突行消失，且所有哈希重新计算匹配
最易被忽略的一点：CI 流程中必须加入 go mod tidy -dry-run 校验。它不改文件，只返回非零码当检测到本地与远程 go.mod 不一致——这是防止“有人忘了 tidy 就提 PR”的最后一道闸。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
