go.mod中require v1.2.0仅表示最低要求，实际版本由MVS算法根据所有依赖约束动态选择最小满足版本，可能低于v1.2.0；需用go list -m all确认真实生效版本。
go.mod里写v1.2.0不代表就用v1.2.0
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 会尽量尊重，但可能被更高优先级依赖覆盖（比如某处 requirev1.3.0） -
v1.2是模糊版本，MVS 可能选v1.2.7（只要存在且语义兼容） - 主版本升级必须显式改 module path，如
example.com/lib/v2，否则v2.0.0不会被识别为新模块
怎么查实际生效的是哪个版本
别信 go.mod 里写的，也别只看终端输出。要确认构建时真正用的版本，得看 build list：
运行 go list -m all，它列出当前构建中每个 module 的最终选用版本。如果 example.com/lib 出现在结果里是 v1.1.5，那它就是真实版本，哪怕 go.mod 写着 v1.2.0。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
再进一步定位谁拉低了版本：用 go mod graph | grep example.com/lib，看哪些模块在引用它，以及各自 require 的版本号。特别注意间接依赖（indirect）项，它们常是“静默降级”的源头。
-
go list -m -versions example.com/lib查所有可用版本，确认v1.2.0是否真的存在且可解析 - 如果某依赖 require
v0.0.0-20240101-h123abc（伪版本），它可能压制语义化版本选择，导致无法升到v1.2.0 -
go mod verify能校验go.sum是否匹配当前 build list，避免哈希不一致引发的隐性问题
如何强制升级并确保生效
想让 example.com/lib 稳定用上 v1.2.0，不能只改 go.mod，得让 MVS “没得选”：
最直接的方式是显式执行 go get example.com/lib@v1.2.0，它会更新 go.mod 并同步 go.sum。但要注意：如果其他模块 require 更高版本（比如 v1.3.0），MVS 仍会选 v1.3.0；如果 require 更低版本（比如 v1.1.0），MVS 仍可能选 v1.1.x 中的某个 patch 版本 —— 此时就得用 -u=patch 或 -u=minor 控制升级粒度。
-
go get -u=patch example.com/lib：只允许升 patch，如从v1.2.0→v1.2.5 -
go get -u=minor example.com/lib：允许升 minor，如从v1.2.0→v1.3.2，但不会跨主版本 - 升级后务必检查
go.mod和go.sum是否都更新了对应条目；若没变，可能是 GOPROXY 缓存或本地$GOPATH/pkg/mod残留，可加-x参数看真实 fetch 日志
replace不是解决方案，只是临时绕过
go mod edit -replace=example.com/lib=example.com/lib@v1.2.0 确实能让构建强制用指定版本，但它绕过了 MVS，也绕过了版本兼容性检查。这不是“解决冲突”，而是“掩盖冲突”。
它适合调试或对接私有 fork，但绝不该提交到主干。一旦提交，CI 构建、其他协作者、甚至你两周后重装环境，都会因 replace 规则缺失或路径失效而失败。
- replace 后，
go list -m all显示的仍是原 module 名，但实际代码来自替换路径 —— 容易误判依赖关系 - replace 不影响
go.sum对原始模块的哈希记录，可能导致校验失败或安全扫描漏报 - 真正稳的做法是：先用
go mod graph找出谁在锁低版本，再联系对应模块维护者升级其 require，或评估是否可移除该依赖
