多分支开发易触发版本抢占，根本原因是go mod tidy默认采用最小版本选择（mvs），仅依据go.mod中的require声明和间接依赖约束，无视分支上下文；feature/a升级lib至v1.5.0而feature/b仍用v1.2.0时，主干执行go mod tidy会强制全项目升至v1.5.0。
为什么多分支开发容易触发版本抢占
根本原因是 go mod tidy 默认执行最小版本选择（MVS），它不看分支上下文，只认当前 go.mod 中的 require 声明和所有间接依赖的约束。当你在 feature/a 分支升级了 github.com/org/lib 到 v1.5.0，而 feature/b 分支仍依赖 v1.2.0，一旦有人在主干上运行 go mod tidy，MVS 就可能把 v1.2.0 “吃掉”，强制全项目升到 v1.5.0——哪怕 feature/b 还没准备好。
用 replace 隔离分支专属依赖
replace 不是临时补丁，而是分支隔离的正式手段。它让同一模块路径在不同分支下解析到不同 commit 或本地路径，且不影响其他分支的 go.mod。
- 在 feature/a 分支的
go.mod末尾加：replace github.com/org/lib => github.com/org/lib v1.5.0
- 在 feature/b 分支保持原
require github.com/org/lib v1.2.0，不加replace - 切回主干前务必删掉
replace行——否则会被提交，破坏主干稳定性 - 禁止用
replace github.com/org/lib => ./local-fix：本地路径无法被 CI 构建，且易被误提交
避免 go mod tidy 自动覆盖分支状态
go mod tidy 会重写 go.mod 和 go.sum，抹掉你手动维护的分支差异。这不是 bug，是它的设计目标——但和并行开发冲突。
- 所有分支开发期间，禁用自动
go mod tidy；CI 流水线中也应跳过该步骤，改用go build+go test验证即可 - 需要同步依赖时，显式执行：
go get github.com/org/lib@v1.2.0（而非@latest），再手动检查go.mod是否只改了目标行 - 把
go.sum提交进 Git：它记录的是当前分支实际使用的校验和，不是“全局真理”
真正要盯住的不是版本号，是 go.sum 里的哈希冲突
两个分支共存时，go list -m all 显示多个版本完全正常；但若 go.sum 中同一模块出现两行不同 hash，说明构建环境已混入不一致状态——这往往是 CI 失败或本地编译失败的真正源头。
遇到这种情况，不要直接 go mod tidy，先用 go mod graph | grep org/lib 查清谁拉入了哪个版本，再决定是升级、replace 还是联系对应依赖方确认兼容性。分支合并前，必须确保 go.sum 中每个模块只有一行有效 hash，且与 go.mod 中声明的版本严格对应。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
