go mod tidy 不会自动升级到 v2+ 是因它仅按代码中 import 路径匹配模块，未写 import "x/v2" 就不会解析或拉取 v2，与远程是否存在无关；其目标是满足所有现有 import 的最小可行版本，不主动切换路径。
为什么 go mod tidy 不会自动跳过 v2+ 升级
因为 go mod tidy 的目标是“满足所有 import 路径的最小可行版本”，它不区分破坏性与否——只要你的代码里写了 import "github.com/some/lib/v2"，它就会拉 v2；如果没写，它就永远只认 github.com/some/lib 这个路径，哪怕远程仓库已发布 v2.0.0 且带 /v2 后缀，也不会主动切换。所谓“忽略破坏性大版本”，本质是不让 Go 解析到那个新路径。
用 require + // indirect 锁定旧主版本
当某个间接依赖（比如 A → B → C v2.0.0）试图把你拖进新主版本，但你代码里根本没用 C，也不希望它进来，最稳的方式是在 go.mod 中显式声明旧版并标记为间接：
- 手动在
go.mod的require区块末尾加一行：github.com/some/lib v1.8.1 // indirect - 确保这行没被其他
require覆盖（比如没有另一行github.com/some/lib/v2 v2.0.0） - 运行
go mod tidy，它会保留该行，并拒绝解析任何/v2路径 - 验证：执行
go list -m all | grep some/lib，应只输出v1.8.1，无v2
replace 不是忽略，而是绕过校验的临时补丁
replace 会让 Go 完全跳过远程模块解析，直接用你指定的本地或 fork 路径。它不能“忽略”升级，只能“覆盖”行为：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 仅限开发调试：比如你 fork 了
some/lib并 patch 了 v1 分支，想验证兼容性，可加：replace github.com/some/lib => ./forks/lib-v1 - CI 或生产构建中必须删除
replace行，否则go.sum失效，go mod verify会失败 - 它会影响整个模块树中所有对
github.com/some/lib的引用，不是局部控制 - 如果只是想防升级，
replace是过度操作，且掩盖了真正的问题来源
排查谁偷偷引入了 v2 版本
当你发现 go list -m all 里突然冒出 github.com/some/lib/v2 v2.0.0，但自己没动过 import，说明有依赖项升级了自身 require：
- 用
go mod graph | grep 'some/lib/v2'找出哪条路径引入了它 - 再用
go mod why github.com/some/lib/v2看具体 import 链 - 常见元凶：某工具库（如 CLI 框架、测试辅助包）悄悄升级了它的
require，而你又用了它的新版本 - 解决方案不是硬锁，而是降级那个工具库版本，或联系其维护者确认是否必须依赖 v2
真正要“忽略破坏性大版本”，靠的不是命令开关，而是路径隔离和显式约束——Go 不让你同时 import v1 和 v2，但允许它们共存，前提是路径不同；一旦你没写 /v2，Go 就不会加载它，无论远程是否存在。关键在 import 语句和 go.mod 的 require 路径是否干净。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
