go mod tidy仅删除既未被任何.go文件import语句引用、也未被其他已保留模块间接依赖的模块；它不识别反射调用、配置驱动或测试专用模块，需人工交叉验证。
go mod tidy 会删掉哪些依赖
go mod tidy 的核心行为是：只保留当前项目中 import 语句实际用到的模块，同时补全间接依赖（require 中缺失但被依赖链需要的模块）。它不会删掉 replace 或 exclude 指令，也不会动 go.sum 里已验证过的校验和。
常见误判场景：
- 代码里注释掉了
import，但go mod tidy仍会保留——Go 不解析注释，只看语法树上的导入声明 - 测试文件（
*_test.go）里的import会被计入，即使主逻辑没用到 - 条件编译（如
// +build ignore）若未生效，其import仍可能被保留
如何确保真正“多余”的依赖被清理
仅靠 go mod tidy 不够，因为 Go 不分析运行时反射、字符串拼包名、插件式加载等动态依赖。需人工辅助确认：
- 先执行
go mod graph | grep 'your-module'查该模块是否被任何其他模块引用 - 用
go list -deps -f '{{if (eq .Name "main")}}{{.ImportPath}}{{end}}' ./...看哪些包最终被主模块直接或间接导入 - 临时删掉某
require行，再go build ./...—— 若报cannot find package，说明它还没被彻底移除
go mod vendor 后还能用 tidy 清理吗
可以，但要注意：go mod tidy 只操作 go.mod 和 go.sum，不碰 vendor/ 目录。清理完后，必须手动运行 go mod vendor 同步更新 vendor 内容，否则本地构建可能仍使用旧依赖。
更稳妥的做法是：
- 先
go mod tidy - 再
go mod vendor - 最后检查
vendor/modules.txt是否与go.mod中的require条目一致
CI/CD 中自动清理的注意事项
在自动化流程里直接跑 go mod tidy -v 并提交变更，容易引发问题：
- 不同 Go 版本对最小版本选择策略不同，
go mod tidy可能升级次要版本，导致兼容性断裂 - 如果项目依赖某个模块的特定 commit（通过
go get module@commit），tidy可能将其降级为 tag 版本 - 建议在 CI 中只做验证：用
go mod tidy -v && git diff --quiet go.mod go.sum，有差异则失败并提示开发者手动处理
真正自动清理适合本地开发阶段，上线前仍需人工核对依赖变更日志，尤其关注 major 版本跃迁和许可协议变化。
