go mod tidy不能替代构建前检查，因为它仅静态分析import语句，无法识别测试文件、注释代码、反射/插件动态加载等场景导致的误保留依赖，需配合go list、go mod graph、go mod why等命令人工验证依赖真实性。
go mod tidy 是构建前必须执行的依赖整理动作，它能同步 go.mod 与实际代码中的 import 关系——但仅靠它不够，必须配合人工验证和构建路径控制。
为什么 go mod tidy 不能替代构建前检查
这个命令只看源码里有没有 import 语句，不关心包是否被真正调用。比如：
- 测试文件（
*_test.go）里导入的包会被保留，即使主程序完全不用 - 被注释掉的代码仍保留
import行，go mod tidy不会删 - 通过反射或插件机制动态加载的包（如
database/sql驱动），import存在但无显式调用，也会被误判为“已使用”
所以运行完 go mod tidy 后，go.mod 里仍可能残留冗余 require 条目，尤其在长期迭代的老项目中。
构建前必须确认的三个依赖状态
在执行 go build 前，建议依次验证以下三点：
立即学习“go语言免费学习笔记（深入）”；
- 运行
go list -m all | grep 'indirect'，检查间接依赖数量是否异常膨胀；若超过直接依赖的 2 倍，大概率存在未收敛的传递依赖 - 用
go mod graph | grep 'your-module-name'快速定位某模块是否被多个路径引入，避免版本冲突隐患 - 执行
go mod why -m github.com/some/unused-package，确认某个可疑包为何还在依赖图中——它可能是某已弃用组件的残余依赖
这些命令不修改文件，但能暴露 go.mod 表面之下真实的依赖压力点。
CI 流程中如何防止脏依赖进入构建
本地整理干净不等于 CI 构建也干净。常见断点是：go.mod 和 go.sum 没提交、或 go build 路径不对导致跳过模块校验。推荐在 CI 脚本中加入：
git diff --quiet go.mod go.sum || (echo "go.mod or go.sum changed but not committed"; exit 1)go mod tidy -v && git diff --quiet go.mod go.sum || (echo "go mod tidy would change files"; exit 1)- 始终用
go build ./...或go build ./cmd/...，避免单文件构建（如go build main.go）绕过模块解析
最后一项最容易被忽略：单文件构建不会触发 go.mod 校验，可能链接到旧缓存或错误版本的依赖。
真正麻烦的不是依赖多，而是某些包在 go.mod 里写着 // indirect 却又找不到谁在用它——这种幽灵依赖往往藏在 vendor/ 或老版 replace 规则里，需要 go mod graph 加 go list -m -json all 联合排查。
