go mod tidy是唯一安全、可复现的清理方式，但需配合验证：它仅基于import语句静态分析，无法识别空白导入、反射/插件加载、//go:embed、测试文件及条件编译中的依赖，故必须运行go build ./、go test ./和go mod why等交叉验证。
直接结论：用 go mod tidy 是唯一安全、可复现的清理方式，但必须配合验证步骤，否则极易导致运行时 panic 或构建失败。
为什么不能只靠 go mod tidy 就完事
go mod tidy 只看 import 语句，对以下情况完全无感：
- 数据库驱动类的空白导入：
import _ "github.com/lib/pq"—— 如果删了，sql.Open("postgres", ...)会 panic - 通过
reflect.ImportPath或插件机制（plugin.Open）加载的模块 —— 静态分析根本看不见 -
//go:embed引用的包（如 embed.FS 依赖的golang.org/x/tools子模块）—— 不算 import，会被误删 - 仅在
_test.go文件里 import 的模块 —— 默认不扫描测试文件，除非你显式加-modfile go.sum或确保GOOS环境一致
go mod why -m xxx 比扫 go.mod 更可靠
别光看 go.mod 里有没有那行 require，得确认它是否真被构建图需要：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
go mod why golang.org/x/net/http2→ 显示调用链，若返回main module does not need module，才是安全信号 -
go mod why -m github.com/spf13/cobra -test→ 加-test才能暴露测试专用依赖 - 如果输出路径含
vendor/或internal/子目录，说明它被子模块 require，根目录跑tidy不会动它
清理后必须跑的三件事，缺一不可
删完不验证 = 白删，尤其要注意非主干路径：
-
go build ./→ 必须覆盖cmd/下所有二进制，有些命令只在特定GOOS下编译 -
go test ./→ 测试可能引入独立依赖（比如github.com/onsi/ginkgo/v2），且go mod tidy默认处理它们，但得实测 -
go list -m all | wc -l→ 对比清理前后数字，下降明显才说明真删了；再跑一次go mod graph | wc -l看边数是否减少
容易被忽略的复杂点
真正踩坑的地方不在命令本身，而在环境与上下文：
-
//go:build integration标记的代码，若当前没启用该 tag，go mod tidy就当它不存在 —— 清理前得先GOOS=linux go build -tags=integration ./过一遍 - 生成代码（如
protoc-gen-go输出的.pb.go）里的import，必须先执行生成逻辑，再跑tidy，否则会被当成“未引用”删掉 - 手动加过
replace或exclude的模块，tidy会保留它们，但可能已失效 —— 得人工核对go mod graph输出里是否还有引用路径
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
