go 的最小版本选择（MVS）是在满足所有依赖约束前提下选取的最低兼容版本，而非最旧版本；它确保确定性、可复现与稳定性，同 major 内选最小可行版本，跨 major 则并存。
Go 的最小版本选择（Minimal Version Selection，MVS）不是“挑最老的版本”，而是选满足所有依赖约束的最低兼容版本。它追求的是确定性、可复现和稳定性，而不是盲目升级或保守锁死。
它解决的核心问题
当多个模块依赖同一个第三方库（比如 logrus），但各自声明了不同版本要求时，Go 需要决定最终用哪一个版本——既不能让某个依赖“掉链子”，也不能无故升级引入不兼容变更。
- 模块 A 要求
github.com/sirupsen/logrus v1.4.0 - 模块 B 要求
v1.8.0 - 模块 C 要求
v1.10.0
这时 MVS 会选择 v1.10.0 —— 因为它是能同时满足三者要求的最小版本（v1.4.0 和 v1.8.0 都不满足 C 的要求；v1.10.0 是第一个满足全部的）。
关键逻辑：不是“最小数字”，而是“最小满足”
MVS 不是按字典序或语义版本号简单比大小，而是在所有被间接引用的版本中，找出能覆盖全部依赖约束的最低版本。
- 如果某依赖只写
require github.com/foo/bar没指定版本，Go 默认取该模块的最新major下最高 tag（如v2.5.0） - 如果两个依赖分别要求
v1.2.0和v1.5.0，MVS 选v1.5.0（因为v1.2.0不满足后者） - 如果出现
v1.9.0和v2.1.0，它们属于不同主版本，Go 会同时保留两个，不强行统一（MVS 只在同 major 内做选择）
你日常会接触到的 MVS 场景
go mod tidy 是最典型的 MVS 触发点：它会重新计算整个依赖图，按 MVS 规则降级或升级间接依赖，并更新 go.mod 中的 require 行。
- 删掉一个依赖后，原来被它“拉高”的某个库版本可能被自动降级
- 加了一个新依赖，可能导致多个已有库版本被动升级以满足其约束
-
go.sum文件里的哈希记录，始终对应 MVS 最终选出的那个版本的校验值
为什么叫“最小”却不总选旧版？
名字容易误解，其实“最小”指的是：在满足所有依赖前提下，版本号数值最小的那个可行解。它本质是一个“下界满足型”算法——不是越老越好，而是“刚刚好够用”。这避免了因随意升版导致的 breakage，也防止了因锁死旧版带来的安全与功能滞后。
基本上就这些。