Go模块依赖下载采用最小版本选择（MVS）算法，优先选满足所有约束的最低兼容版本而非最新版；显式请求（如@latest或go get -u=patch）或go mod tidy会触发MVS重算，但不会跨主版本升级，v2+需带/v2路径才被识别。
Go模块依赖下载不是“最新版优先”，而是由语义化版本规则 + 最小版本选择（MVS）算法共同决定的——你指定的版本范围越宽，Go越倾向于选最低兼容版本，而不是最高；只有显式请求（如 @latest）或 go mod tidy 重新解析时，才可能升级到更高 patch/minor 版本。
go get @vX.Y.Z 和 @latest 的行为差异
很多人以为 go get github.com/sirupsen/logrus@latest 总是拉取 v2.x，其实它只取当前主版本下的最新稳定版（即 v1.x.y 中最高的那个），前提是模块路径没带 /v2 后缀。
-
go get github.com/sirupsen/logrus@v1→ 解析为该模块最新的v1.x.y版本（比如v1.9.0） -
go get github.com/sirupsen/logrus@v1.8→ 解析为最新的v1.8.x（比如v1.8.5） -
go get github.com/sirupsen/logrus@latest→ 等价于@v1，不会跨 major 升级 -
go get github.com/sirupsen/logrus@v2.0.0→ 失败，除非导入路径写成github.com/sirupsen/logrus/v2，否则 Go 拒绝解析 v2+
为什么 go mod tidy 有时降级、有时升级？
go mod tidy 不是“更新到最新”，而是重新运行 MVS 算法：扫描所有 import 语句和间接依赖约束，选出满足全部要求的**最低可行版本**。这意味着：
- 如果你代码里只 import
github.com/gin-gonic/gin（无 /v2），而另一个依赖要求gin v1.8.0，即使你本地go.mod写着v1.9.1，tidy也可能把它降到v1.8.0 - 如果某依赖被多个模块以不同 minor 版本引入（如 v1.7 和 v1.9），MVS 会选择 v1.9 —— 因为它是满足两者的最低版本
-
go.sum中记录的是实际下载的版本哈希，不是go.mod里写的“目标版本”；tidy可能改写go.mod，但不会动go.sum里的旧条目（除非真正下载新版本）
主版本 ≥2 必须带 /vN 路径，否则根本无法解析
这是 Go 模块最常踩坑的点：v2+ 模块不是“换个版本号就行”，而是**逻辑上完全独立的新模块**。不加 /v2 就等于告诉 Go：“我要的是 v1 分支”。
- 正确用法：
import "github.com/robfig/cron/v3"+require github.com/robfig/cron/v3 v3.0.1 - 错误写法：
import "github.com/robfig/cron"+require github.com/robfig/cron v3.0.1→go build报错：cannot find module providing package github.com/robfig/cron - 伪版本（如
v0.0.0-20240101120000-abc123）不受此限，但仅用于开发调试，生产环境应避免
replace 和 exclude 不改变 MVS 逻辑，只绕过默认解析
replace 和 exclude 是“覆盖规则”，它们在 MVS 执行前生效，但不参与版本比较。也就是说：
-
replace github.com/gorilla/mux => ./local-mux：无论go.mod里 require 的是v1.8.0还是v1.9.0，都强制用本地目录；但你的本地代码仍需兼容原模块的 API -
exclude github.com/gorilla/mux v1.8.0：当 MVS 计算出 v1.8.0 是“最低可行版本”时，会跳过它，尝试 v1.8.1 或更高（只要满足所有约束） - 二者都只作用于当前模块，不影响下游依赖；若子模块也 require 同一模块，它仍按自己的
go.mod解析
真正容易被忽略的，是 MVS 的“全局最小性”——它不看你的主观意愿，只看所有 import 路径和 require 约束形成的数学解集。一个 indirect 依赖的微小变动，可能让整个依赖树重排。别迷信 @latest，也别手动锁死 patch 版本，关键是在 go.mod 里留下可读的约束意图，并用 go list -m all 和 go mod graph 验证实际解析结果。
