必须提交go.mod和go.sum到Git并一起更新，CI首行执行go mod verify拦截不一致，PR强制附go list -m输出，replace仅限开发分支且禁入主干，GOPRIVATE需全局配置确保私有模块稳定解析。
多人协作时，不同分支上 go.mod 和 go.sum 出现不一致，是构建失败和本地复现困难的最常见源头。核心对策不是“同步动作”，而是“统一约束 + 自动拦截”——靠流程卡点，而不是靠人肉对齐。
go.mod/go.sum 必须提交到 Git，且禁止忽略
这是所有后续操作的前提。很多团队把 go.sum 加进 .gitignore，认为“哈希值会变”，结果导致：
• CI 构建用的是远程下载的模块，而开发者本地用的是缓存或不同代理拉的版本
• go mod verify 在 CI 失败，但本地不报错
• 同一 commit 在不同环境构建出不同二进制
-
go.mod和go.sum都要提交，且必须一起提交（增删改 require 时，go.sum必须更新） - CI 流水线第一行加
go mod verify，失败即终止，不给“先过再说”机会 - 开发机本地可配 Git hook（如 pre-commit），自动运行
go mod tidy && git add go.mod go.sum，避免漏提
多分支并行开发时，如何避免 go.mod 冲突升级？
典型场景：feature-a 分支升级了 github.com/some/lib 到 v1.5.0，feature-b 还在用 v1.4.2，合并前没人检查依赖兼容性，一合就炸。
- 不要等 merge 时才发现冲突——在 feature 分支 PR 描述中强制要求附带
go list -m github.com/some/lib输出，确认版本意图 - 主干（如
main或develop）设为唯一可信源，所有 feature 分支基于它切出；升级依赖只允许在主干完成，再通过 fast-forward 合并回各分支 - 若必须在 feature 分支提前升级（如修复紧急漏洞），需同步提一个“依赖对齐”PR，将该版本显式写入主干的
go.mod，再让其他分支 rebase 上去
replace 指令在多分支中怎么管？
replace 是本地调试利器，但极容易误提交、误继承、误发布。它不会跨模块生效，也不进 go.sum 校验范围，一旦混进长期分支，后果严重。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
replace只允许出现在开发分支（如dev或feature/*），绝对禁止出现在main、release/*等交付分支 - CI 中加检查：
grep -q "replace" go.mod && exit 1 || true，在 release 流程里直接拒掉含replace的构建 - 本地开发时，可用
// replace: github.com/xxx => ../xxx注释代替真实replace行，配合脚本临时注入（如 Makefile 中sed -i '' 's|// replace:|replace:|' go.mod），避免手滑提交
私有模块 + 多分支 = GOPRIVATE 必须全局生效
当项目依赖 git.company.com/internal/pkg，而不同分支使用不同 Git 仓库策略（如 dev 分支走内部代理，release 分支直连），go mod download 就会因权限或路径解析失败中断。
-
GOPRIVATE=git.company.com/*必须设为 shell 环境变量（不是仅 CI 脚本里 export），确保go命令任何位置都能识别私有域 - 若用 Athens 等私有代理，
GOPROXY应设为https://athens.company.com,direct，末尾direct是 fallback，防止代理宕机时全链路阻塞 - 验证方式：在任意分支执行
go list -m all | grep company，应能稳定列出模块，且无unknown revision报错
真正难的不是技术方案，而是让所有人习惯在 go.mod 变更后立刻跑一遍 go mod tidy && go mod verify，并在 PR 描述里写清楚“这次改了哪些依赖、为什么、是否影响其他模块”。工具可以拦住错误，但拦不住模糊意图。
