go mod tidy 不自动解决重复依赖，因其遵循最小版本选择（MVS）机制，仅保留满足语义化约束的最高版本，不降级或替换间接依赖；需用 replace 或显式 go get 统一版本。
go mod tidy 为什么不能自动解决重复依赖？
因为 go mod tidy 只保证当前模块的 go.mod 中声明的依赖是最小闭包，它不会降级或替换已存在的间接依赖——哪怕两个不同主版本（如 v1.2.0 和 v1.5.0）被不同子模块引入，只要都满足 require 的语义版本约束，Go 就会保留较高版本，并让所有调用方共享它。这不是 bug，是 Go Module 的“最小版本选择”（MVS）机制决定的。
常见现象：运行 go list -m all | grep some-package 发现同一包出现多个版本；go build 成功但测试里某函数行为异常，实际是因高版本中删了旧 API，而某个依赖仍按低版本文档在用。
- 不要指望
go mod tidy“清理冗余”，它只做必要性判断，不判断兼容性 - 若想强制统一某依赖版本，需显式
go get package@vX.Y.Z，再执行go mod tidy -
go mod graph可查谁引入了哪个版本，例如：go mod graph | grep "github.com/some/pkg@"
如何定位并替换间接依赖的特定版本？
当 go list -m all 显示 example.com/dep v0.3.1 被间接引入，但你发现它有 panic bug，而 v0.4.0 已修复，此时不能直接改 go.mod 里的 require（因为没直接 import），必须用 replace 或升级其上游。
推荐优先走 replace 路径，尤其在上游未发布修复版或你需临时验证时：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在
go.mod末尾添加：replace github.com/example/dep => github.com/example/dep v0.4.0 - 执行
go mod tidy，Go 会把所有对该包的引用重定向到v0.4.0 - 注意：如果
v0.4.0引入了不兼容变更，编译失败是正常反馈，需同步调整你的代码 -
replace不会改变go.sum中原有校验和，但会新增新版本的 checksum 行
vendor 目录下为何仍有旧版包？
启用 go mod vendor 后，目录里可能同时存在 some/pkg@v1.2.0 和 some/pkg@v1.5.0 的子目录，这不是错误，而是 Go vendor 机制的保守策略：它把每个被记录在 go.mod 中的版本都完整拷贝进来，不管是否实际被构建使用。
这容易误导人以为“重复依赖没清理干净”，其实只要 go build 时用的是统一版本（可通过 go list -m some/pkg 确认），vendor 里的多版本只是冗余缓存。
- vendor 中的重复不影响运行时行为，只增加磁盘占用
- 如需精简 vendor，可先
go mod vendor -o /dev/null触发重建，再手动删除未被go.mod记录的子目录（不推荐自动化删） - CI 环境建议禁用 vendor，直接用
GO111MODULE=on go build，避免 vendor 与 mod 不一致
gomodgraph 或 gomodifytags 这类工具真能帮上忙吗？
能，但作用有限。像 gomodgraph 可视化依赖树，帮你快速识别哪条路径拉进了老版本；go-mod-outdated（非官方）能列出可升级的依赖及当前版本是否过期。但它们都不修改 go.mod，也不能自动判断“该不该升”。
真正关键的决策点永远在人：某个 indirect 依赖升级后是否破坏下游？它的更新日志有没有提 ABI 变更？你的测试能否覆盖它暴露的接口？
-
go list -u -m all查可升级项，-u会显示最新可用版本 -
go mod why -m example.com/dep查明为何引入该包（含具体 import 链） - 别迷信工具输出的“安全升级建议”，
v1.9.0 → v2.0.0很可能意味着导入路径已变（/v2后缀），必须手动改 import
replace 语句未随团队同步、或上线前忘了删掉本地调试用的 replace，导致构建环境拉取的是原始版本——这种问题往往要等到线上 panic 才暴露。 
