因为go采用最小版本选择（mvs）算法，require v1.2.0仅表示最低要求，实际选用满足所有依赖约束的最小可行版本（如v1.1.5），需用go list -m all确认真实生效版本。
为什么 go.mod 里写 v1.2.0，运行时却加载 v1.1.5
Go 不会照着 go.mod 里写的 require example.com/lib v1.2.0 直接锁定这个版本。它只把这行当作“最低要求”，真正选哪个，由 MVS（Minimal Version Selection）算法在 go build 或 go mod tidy 时动态决定。
常见错误现象：你刚 go get example.com/lib@v1.2.0，go.mod 看起来也更新了，但运行时却报 panic——查发现实际加载的是 v1.1.5。原因很可能是另一个依赖（比如 github.com/xxx/yyy）只要求 example.com/lib v1.1.0，MVS 就选了满足所有约束的最小版本 v1.1.5（比 v1.1.0 新，但比 v1.2.0 旧）。
-
v1.2.0是精确版本，MVS 会尽量尊重，但可能被更高优先级依赖覆盖（比如某处require v1.3.0） -
v1.2是模糊版本，MVS 可能选v1.2.7（只要存在且语义兼容） - 主版本升级必须显式改 module path，如
example.com/lib/v2，否则v2.0.0不会被识别为新模块
怎么确认当前项目实际用的是哪个版本
别信 go.mod 里写的，也别信终端输出的 go get 成功提示。唯一可靠的方式是执行：
go list -m all | grep example.com/lib
这条命令输出的是整个构建图最终采纳的版本，是 MVS 全局计算后的归一化结果。
-
go mod graph | grep example.com/lib只显示局部依赖边，比如A → example.com/lib@v1.2.0，但它不反映最终生效版本 - 如果多个模块对同一依赖有冲突约束（比如一个要
v2.0.0，另一个只兼容v1.x），go build会直接失败并报错version conflict -
indirect标记的依赖不可信，它只是“当前没被直接 import”，下次go mod tidy可能消失或跳变
如何强制升级到指定版本并让 MVS 接受
不能靠手动改 go.mod 一行就生效，MVS 会回退或忽略。必须用 go get 显式触发重计算：
- 升级单个模块：
go get example.com/lib@v1.2.0 - 升级并同步所有间接依赖：
go get -u example.com/lib@v1.2.0 - 保守升级（只升补丁）：
go get -u=patch example.com/lib@v1.2.0—— 它不会跨v1.2 → v1.3，破坏性更小
执行后务必检查 go.mod 和 go.sum 是否真实更新，特别是新增了哪些 // indirect 行——那是 MVS 推导出的新约束，不是你写的。
如果被其他模块锁死低版本，得先查谁在拉旧版：go list -m -versions example.com/lib，再看依赖图：go mod graph | grep lib。
replace 和 exclude 的真实作用与风险
replace 和 exclude 是干预 MVS 的最后手段，但它们不改变语义约束本身，只影响解析结果：
-
replace能绕过 MVS 强制指定路径或版本，但只对当前 module 生效，下游无法继承；慎用replace指向本地路径，CI 环境没那目录就失败 -
exclude会彻底剔除某个版本，但如果别的依赖硬编码要求它，go build会直接报错require : version ... excluded by ... - 临时调试可用
go mod edit -replace=old=new，但别提交到主干 -
replace与 major version bump 共存时容易分裂go.sum校验，导致校验失败
MVS 的复杂性不在规则多，而在它永远从整个依赖图出发做全局最小解——你改一行 require，可能触发二十个模块的版本重协商。真要稳，就得接受它，然后用 go list -m all 和 go mod graph 看清实际生效的是哪一版。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
