最小版本选择（MVS）选的是满足所有依赖的最低可行版本，而非最新版；例如 A 依赖 v1.2.0、B 依赖 v1.5.0 时选 v1.5.0，以平衡稳定性与“卡旧”风险。
最小版本选择（MVS）不是选“最新”，而是选“最低兼容”
Go 默认不升级到最新版，而是用 Minimal Version Selection 算法找出满足所有依赖约束的 ** 最低可行版本 **。比如 A 依赖 github.com/user/lib v1.2.0，B 依赖 github.com/user/lib v1.5.0，Go 会选 v1.5.0——不是因为新，而是因为它是同时满足两者要求的最低版本。
- 好处是构建更稳定：避免因自动升到 v1.9.0 引入未测试的变更
- 坏处是容易“卡旧”：如果没人显式 require 新版，项目可能长期停留在 v1.5.0，错过安全修复
- 验证方式：
go list -m all | grep user/lib查看实际选用版本；
go mod graph | grep user/lib查看谁在拉这个模块
主版本号必须体现在导入路径里，否则无法共存
Go 不允许 github.com/user/lib v1.8.0 和 github.com/user/lib v2.1.0 同时存在——除非 v2 版本的模块路径明确写成 github.com/user/lib/v2。这是硬性规则，不是配置能绕过的。
- 常见错误：发布 v2 后没改
module声明，导致 go get 拉不到 v2，或拉了却 import 失败 - 正确做法：v2+ 模块的
go.mod第一行必须是module github.com/user/lib/v2，代码中 import 也得写import "github.com/user/lib/v2" - 后果很直接：不加
/v2，Go 工具 链会把 v2.0.0 当作非法版本拒绝处理
生产环境别信“用了两年没出问题”，只看官方支持窗口
Go 官方对每个小版本（如 1.21.x、1.22.x）只维护约 12 个月：前 6 个月修 bug + 安全漏洞，后 6 个月只修高危漏洞。2026 年初，Go 1.21.x 已结束支持（截至 2024 年 8 月），Go 1.22.x 支持到 2025 年 2 月，当前受支持的是 Go 1.23.x 和 Go 1.24.x（假设已发布）。
- 查支持状态最准的方式：go.dev/dl 页面底部的“Supported versions”表格
- 执行
go version后，去 go.dev/doc/devel/release 查对应版本的生命周期 - CI/CD 中硬 编码
go install golang.org/dl/go1.21@latest && go1.21 download这类逻辑，等于主动引入过期风险
依赖冲突时，优先用 replace 临时修复，而非锁死旧版
当两个子模块分别 require 同一库的不兼容版本（如 v1.7 和 v2.3），又无法推动上游统一，replace 是比 exclude 更可控的选择。
立即学习“go 语言免费学习笔记（深入）”；
-
replace显式指定用哪个版本或路径，不影响其他模块解析逻辑 - 示例：
replace github.com/some/pkg => github.com/forked/pkg v2.3.1或本地调试时：
replace github.com/some/pkg => ./vendor/some-pkg - 避免滥用
exclude：它只是“禁止使用某版本”，但 Go 仍会尝试找更高版满足依赖，可能引发更隐蔽的解析失败 - 上线前务必删掉
replace（或确认其指向的是已发布的 tag），否则构建不可重现
真正卡住人的，往往不是“怎么选版本”，而是没意识到 MVS 的结果由整个依赖图共同决定——你改一行 require，可能让下游十几个模块的版本全变。每次 go mod tidy 后，记得看 go.mod 里被自动升级的项，尤其关注主版本号变化。
