mvs（最小版本选择）是从所有依赖约束中选出满足全部要求的最低兼容版本，而非最新版，因其基于semver向后兼容假设、避免意外升级、保障构建可重现性。
什么是MVS，它不选最新版本的原因
MVS（Minimal Version Selection）不是“挑一个能用的最新版”，而是从所有依赖声明中算出满足全部约束的最低兼容版本。比如你的代码直接 require github.com/gorilla/mux v1.8.0，而你引入的另一个库 require github.com/gorilla/mux v1.9.0，MVS 就会选 v1.9.0——因为它既满足你，也满足那个间接依赖，且是两者约束下的最小共同版本。
这个设计背后有明确工程权衡：
- 语义化版本（SemVer）承诺：只要主版本号不变，新版本应向后兼容；MVS 假设 v1.8.0 能跑的代码，在 v1.9.0 里也能跑
- 避免“意外升级”：npm 的
^1.8.0可能拉来 v1.99.0，Go 不这么做；MVS 只升到“必须升”的程度 - 构建可重现性：同一份
go.mod在任何机器上运行go mod tidy，得到的依赖图一致
go mod tidy 怎么触发 MVS 计算
go mod tidy 不是简单补全缺失依赖，它会：
- 扫描所有
.go文件里的import，收集直接依赖 - 递归读取每个依赖模块的
go.mod，提取它们各自的require声明 - 把整个依赖图扁平展开，对每个模块运行 MVS 算法：列出所有路径上出现的版本，取最大值（即满足所有路径的最小共同版本）
- 删掉未被 import 的
require条目，更新go.sum中对应哈希
所以如果你手动改了 go.mod 里的某个版本号，下次 go mod tidy 会把它覆盖掉——因为 MVS 结果优先级高于手写值。真要固定版本，得用 go get github.com/gorilla/mux@v1.8.0 或 go mod edit -require=github.com/gorilla/mux@v1.8.0。
replace 和 exclude 如何绕过 MVS
replace 和 exclude 是对 MVS 结果的显式干预，但机制完全不同：
-
replace github.com/gorilla/mux => ./local-mux：编译时所有对该包的import都指向本地路径；go.sum里仍保留远程v1.9.0的哈希，但不校验本地目录 -
exclude github.com/bad/pkg v1.2.3：MVS 过程中跳过这个版本，哪怕它是当前约束下“本该选”的最小版本；常用于规避已知 panic 的 patch 版本 - 两者都会让
go list -m all输出带// excluded或// indirect标记，方便排查实际生效版本
为什么 go.sum 不是锁文件
go.sum 存的是每个模块每个版本的哈希（h1:xxx），只用来校验下载内容是否被篡改，不参与版本决策。它不会锁定 github.com/gorilla/mux 必须用 v1.8.0——那个决定由 go.mod 中的 require 下限 + MVS 共同完成。
容易踩的坑：
- 删掉
go.sum后执行go mod tidy，会重新下载并生成新哈希，但版本可能和之前不同（因为网络上模块作者可能发布了新 patch 版本，MVS 会选它） - 误以为
go.sum能防止升级：它防不了，go get -u或上游依赖升级都可能带来新版本，go.sum只确保你拿到的是作者发布的那个版本的内容
MVS 的复杂点不在算法本身，而在它和语义化版本、模块路径、主版本后缀（如 /v2）耦合极深——漏掉一个 /v2，Go 就当它是另一个模块；主版本升到 v2 却没加后缀，go build 直接报 cannot find module providing package。这些边界条件，才是日常调试里最耗时间的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
