go mod tidy 升级不该升级的依赖是因 MVS 全局计算最小版本集合，某间接依赖被其他模块的高版本要求拉高；应显式 require 所需版本并用 exclude 控制高版本。
为什么 go mod tidy 会升级不该升级的依赖版本
因为 Go 的 Minimal Version Selection（MVS）机制不选“最新”，而选“满足所有需求的最小版本集合”——但这个“最小”是全局计算出来的，不是逐个模块看的。你只改了一个 go.mod，Go 会重新跑一遍整个依赖图的版本求解，可能把某个间接依赖从 v1.2.0 拉到 v1.5.0，只因另一个模块要求 ≥ v1.5.0。
常见错误现象：go mod tidy 后 CI 突然失败，本地能跑但测试 panic，查日志发现某个函数不见了——其实是那个间接依赖在 v1.5.0 里删了旧 API。
- 别手动改
require行来“锁死”间接依赖；Go 不认这种写法，下次tidy就被抹掉 - 真正起作用的是：让直接依赖显式声明你需要的版本，比如你用到了
github.com/sirupsen/logrus的某个行为，就把它加进你自己的go.mod里，而不是靠别人带进来 - 执行
go get github.com/sirupsen/logrus@v1.9.3后再tidy，才能确保整个图里它不会被升到 v2+（如果 v2 是 major break）
如何查看谁在拉高某个依赖的版本
用 go list 查依赖路径最直接。MVS 冲突往往藏在二级、三级依赖里，go mod graph 输出太长难读，而 go list -m -u 只报更新建议，不告诉你“谁在推高”。
实操命令：
立即学习“go语言免费学习笔记（深入）”；
go mod graph | grep 'some-module' | head -20
或者更精准：
go list -f '{{.Path}}: {{.DependsOn}}' -deps 'your-main-package' | grep 'some-module'
- 输出里看到
A → B → some-module@v1.8.0和C → some-module@v2.1.0并存，说明 MVS 必须选 ≥ v2.1.0 才能满足 C - 如果
some-module是你控制的模块，优先升级它的go.mod中对其他模块的require，减少对高版本的传递性拉动 - 注意
replace只影响构建，不影响 MVS 计算；想骗过 MVS，得用exclude（但慎用，它会让某些版本彻底不可见）
exclude 和 replace 在 MVS 中的真实作用差异
exclude 是告诉 MVS：“这个版本不存在，别考虑它”；replace 是说：“这个路径的模块，实际用另一份代码，但版本号照旧参与计算”。很多人以为 replace 能绕过冲突，其实不能——它只是换源，不换约束。
- 错误用法：
replace github.com/xxx => ./local-fix，但local-fix/go.mod里仍 require 一个高版本的yyy，MVS 还是会被它拉高 - 正确做法：如果必须压低某个模块，先
exclude它的高版本（如exclude github.com/xxx v1.10.0），再require一个更低的、兼容的版本 -
exclude不能排除 latest 或 pseudo-version（比如v0.0.0-20230101...），只对语义化版本有效
CI 中 go mod download 失败常因 GOPROXY 缓存了错误的 go.sum
公司内网代理或私有 GOPROXY 如果缓存了某次 go.sum 错误的 checksum（比如模块作者重推了 tag），后续 go mod download 就会校验失败，报 checksum mismatch。这不是你本地的问题，也不是 MVS 的问题，而是 proxy 的一致性缺陷。
- 临时解决：加
-x参数看 curl 日志，确认请求发给了哪个 proxy；然后清空$GOMODCACHE和 proxy 的对应 blob - 长期规避：在 CI 脚本开头加
go env -w GOPROXY=direct，绕过 proxy 直连（适合小团队）；或强制用go mod verify做二次校验 - 注意
go.sum里的 indirect 条目不是冗余的——它记录了 MVS 推导出的间接依赖版本，删掉可能导致下次tidy重新计算出不同结果
MVS 的复杂性不在规则本身，而在它把所有模块的版本约束摊平成一个全局优化问题。你改一行 require，可能触发整个图的重调度。最容易被忽略的，是 go.mod 里没写明的模块，反而成了版本锚点——因为它们的版本由别人决定，你却要为后果买单。
