go mod tidy悄悄升级依赖的根本原因是MVS算法自动选择满足所有依赖约束的最低兼容版本，而非主动升级；你声明的是版本下限，实际生效版本由整个依赖图共同决定。
go mod tidy 为什么悄悄升级了某个依赖？
根本不是 go mod tidy 主动升级，而是它执行时触发了 Go 的最小版本选择（MVS）机制——只要项目中某个直接或间接依赖“要求更高版本”，go mod tidy 就会把整个模块树统一到满足所有约束的最低可行版本。你没改代码、没运行 go get，但 go.mod 里某行 require 的版本号变了，大概率是上游模块在它自己的 go.mod 中悄悄提高了对该依赖的要求。
排查步骤：
- 运行
go mod graph | grep github.com/some/pkg，看谁引入了这个包、各自声明的版本范围 - 对每个上游模块，查它的
go.mod（比如go list -m -f '{{.Dir}}' github.com/upstream/mod进入目录后 cat go.mod），重点看它的require行 - 用
go list -m all | grep github.com/some/pkg确认当前实际生效版本，再和go mod graph输出对比，找出“拉高版本”的那个源头
为什么 go list -m -u 显示可升级，但 go mod tidy 没动它？
go list -m -u 只告诉你“远程有更新”，不反映本地约束是否允许升级。如果某个依赖被多个模块以不同版本范围引入（比如 A 要求 v1.2.0，B 要求 >= v1.5.0），而你当前锁的是 v1.2.0，go list -m -u 会显示 [v1.5.0]，但 go mod tidy 不会升——因为 v1.2.0 仍满足 A 的约束，MVS 不需要它更高。
真正决定是否升级的，是约束交集，不是远程是否存在新版。常见误判点：
立即学习“go语言免费学习笔记（深入）”；
-
go list -m -u输出的[vX.Y.Z]不等于“应该升”，只代表“可升” - 若某依赖行末尾带
// indirect，说明当前无直接 import，go mod tidy更倾向保持现状，除非其他依赖强制拉高 - 执行
go get github.com/some/pkg@v1.5.0才会主动打破现有约束，触发重新计算
replace 后 go mod tidy 还改版本？
replace 是强干预，但它只影响解析阶段，不改变 MVS 的约束逻辑。比如你写了 replace github.com/some/pkg => github.com/fork/pkg v1.3.0，但另一个依赖明确 require github.com/some/pkg v1.4.0，go mod tidy 仍可能报错或降级——因为 fork 的 v1.3.0 不满足 v1.4.0 的语义约束。
更隐蔽的问题：
-
replace指向本地路径（如../some-pkg）时，go mod tidy会把该路径写死进go.mod，但 CI 环境找不到路径，导致构建失败 -
replace不影响go.sum校验：若 fork 的 commit 未打 tag，Go 会生成 pseudo-version（如v0.0.0-20231015120000-abcdef123456），下次go mod tidy可能因哈希不匹配而重拉 - 撤销
replace后必须删掉对应行再跑go mod tidy，否则 Go 仍按旧规则解析
私有模块或 GOPRIVATE 配置失效导致的“假升级”
当 GOPRIVATE=git.example.com/* 没设好，Go 会默认走 proxy.golang.org。如果私有仓库某分支打了同名 tag（比如 v1.2.0），但内容和你内部版本不一致，go mod tidy 可能拉取 proxy 上的“同名不同货”，看起来像升级，实则是源被替换了。
验证方式：
- 检查
go env GOPRIVATE是否包含你的域名，且无拼写错误 - 运行
go get -d github.com/your-org/private@v1.2.0，观察日志里走的是git.example.com还是proxy.golang.org - 对比
go.sum中该模块的校验和：私有源和公共 proxy 的 hash 绝对不同
隐式升级最麻烦的地方不在命令本身，而在它背后依赖图的动态博弈——你看到的版本号，是几十个模块共同投票的结果，不是某一行 require 能单独决定的。
