go mod tidy 不会自动删除旧版本依赖，仅移除完全未被 import 的模块；旧版本若仍被其他依赖间接引用（如 A→B v1.2.3 且 C 也拉入 v1.2.3），则会被保留，需结合 go mod graph 和 go mod edit -droprequire 手动清理。
go mod tidy 不会自动删旧版本依赖，它只删“完全没被 import 的模块”，不是删“旧版本”。要清理旧版本，得靠人工识别 + go mod graph + go mod edit -droprequire。
为什么 go mod tidy 留着旧版本不删
常见错误现象：go.mod 里同时存在 github.com/some/pkg v1.2.3 // indirect 和 v2.0.0，运行 go mod tidy 后 v1.2.3 还在。
原因很直接：只要某个旧版本仍是某个已保留模块的间接依赖（哪怕只是被另一个 require 拉进来的），go mod tidy 就认为它“有用”，不会动。
-
go mod tidy不比较版本高低，也不做语义化版本裁剪 - 它只做“存在性判断”：这个模块路径是否出现在当前导入图中？是否被其他非-indirect 模块 require？
- 如果 A → B v1.2.3，而你又显式
require C v2.0.0，且 C 内部也拉了 B v1.2.3，那 v1.2.3 就会被保留
怎么定位哪个旧版本其实没人用
不能靠肉眼扫 go.mod，得查真实调用链：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 先跑
go mod graph | grep 'some/pkg@v1\.2\.3'—— 如果无输出，说明它已断开引用，可删 - 再确认是否被测试文件或条件编译引用：
GOOS=linux GOARCH=amd64 go list -deps ./... | grep 'some/pkg' - 检查是否有
replace或exclude干扰解析：临时注释掉它们，再跑一次go mod graph
安全删除旧版本的实操步骤
别直接改 go.mod 手动删行 —— 容易破坏校验和或引发 checksum mismatch。
- 用
go mod edit -droprequire=github.com/some/pkg@v1.2.3（注意带版本号） - 立刻运行
go mod tidy -v，看是否报removing unused requirement或报错 - 必须紧接着跑
go build ./和go test ./，尤其关注是否 panic 在 plugin.Open、reflect.ImportPath 或 embed 路径 - 如果失败，说明有隐式依赖（比如某个生成代码工具内部用了它），得回退并查
go list -f '{{.Deps}}' -m github.com/some/pkg@v1.2.3
容易被忽略的复杂点
多模块项目里，旧版本可能藏在子模块的 go.mod 中，主模块 tidy 不会触达；//go:embed 引用的文件路径若含版本号（如 embed.FS 加载了 v1.2.3 下的模板），也会让该版本被静态分析误判为“活跃”；CI 环境若 Go 版本低于本地，go mod graph 解析结果可能不同，导致本地删了、CI 构建失败。
