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