多人协作时go.mod与go.sum合并冲突需删go.sum后运行go mod tidy -v重生成，replace须在合入主干前删除或改用显式版本替换，go.work子模块go版本须一致，启用vendor则必须同步更新vendor/及modules.txt。
go.mod 和 go.sum 冲突导致合并失败
多人同时修改依赖，go.mod 和 go.sum 很容易出现冲突——不是语法错误，而是语义冲突：比如 A 提升了 github.com/sirupsen/logrus 到 v1.9.0，B 却降级到 v1.8.1，Git 合并后文件虽能 syntactically 合法，但 go mod tidy 会立刻报错“mismatched checksums”或“require statement not found”。
关键不是手动删冲突标记，而是让 Go 工具链重新生成一致状态：
- 先保留任一版本的
go.mod（建议选主干分支的），删掉go.sum全文 - 运行
go mod tidy -v，它会重写go.mod并生成全新go.sum - 检查输出里是否有 “downgraded” 或 “upgraded”，确认是否意外回退了关键依赖
- 用
go list -m all | grep 'your-module'验证目标模块版本是否符合预期
replace 指令在合并中被覆盖或残留
replace 是临时开发手段，但极易在合并时出问题：A 分支用 replace example.com/lib => ./local-lib 调试，B 分支没这行，合并后若未清理，CI 构建就会因找不到 ./local-lib 失败；反之，若 B 的 replace 覆盖了 A 的线上版本，本地测试通过、CI 却拉取错误依赖。
安全做法是分场景处理：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 仅在开发分支保留
replace，合入main前必须删除或注释掉 - CI 流水线中加检查：
git diff main...HEAD -- go.mod | grep replace，非零即失败 - 如确需长期替换（如 fork 维护），改用
replace old => new vX.Y.Z显式指定版本，避免相对路径
go.work 文件与子模块 go.mod 版本不一致
工作区模式下，go.work 本身不声明 Go 版本，但每个被 use 的子模块都有自己的 go.mod。若合并时只更新了 go.work 中的路径，却漏掉某个子模块的 go.mod 里的 go 1.22 声明，运行 go build 就会报 go: cannot use go 1.21.6 with go 1.22 mod ——错误信息指向子模块，但根源在合并遗漏。
检查要点很具体：
- 对每个
go.work use的路径，cd 进去执行go version和head -n1 go.mod，确认 Go 版本声明匹配当前环境 - 不要在子模块目录里单独跑
go mod tidy，必须回到go.work根目录统一执行 - 若某子模块仍用旧版 Go，要么升级其
go.mod，要么在根目录用GOROOT切换版本，别混用
vendor 目录未同步更新就提交
启用 vendor 后，go.mod 变更必须同步进 vendor/，否则同事 git pull 后直接 go build -mod=vendor 会失败，报错类似 cannot find module providing package xxx，因为 vendor 里缺新依赖。
合并后必做三件事：
- 运行
go mod vendor（不是go mod tidy） - 用
git status vendor/确认新增/删除的包已纳入暂存区 - 特别注意
vendor/modules.txt是否更新——它是vendor的权威清单，缺失即失效
最易忽略的是：有人合并完只 go mod tidy 就提 PR，却忘了 vendor 是独立状态。只要项目启用了 -mod=vendor，这个步骤就不是可选项。
