go mod tidy只删除未被任何.go文件import语句直接或间接引用的模块；它无法识别init()注册、测试文件、未启用构建tag、反射调用等隐式依赖，需结合go mod why、go mod graph和手动验证。
go mod tidy 为什么删不掉某些依赖
它只删「没被任何 Go 源文件 import 的模块」，但很多依赖藏在 init() 函数、测试文件、或未启用的构建 tag 里，go mod tidy 默认不触碰这些。常见现象是：删完再跑 go list -m all，发现某个 github.com/xxx 还在列表里，但代码里根本没写 import。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确认是否在
*_test.go文件中引用了该模块：运行go list -f '{{.ImportPath}}' ./... | grep test，再逐个检查 - 用
go mod why -m github.com/xxx查它被谁拉进来；如果输出含(in development)或路径含tools，大概率是开发工具链引入的 - 临时加
//go:build !test到主包顶部，再跑go mod tidy，可排除测试专用依赖 - 注意
replace和exclude语句会阻止tidy清理，删之前先看go.mod末尾有没有残留
go mod graph 怎么定位冗余间接依赖
go mod graph 输出的是扁平化边列表，不是树状图，直接 grep 只能看到一级依赖。比如你想知道 golang.org/x/net 是被哪个主力模块拖进来的，go mod graph | grep 'golang.org/x/net' 可能返回 5 行，但你不知道哪一行通向主应用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 反向查：用
go mod graph | awk '{print $2}' | grep 'golang.org/x/net' | sort -u得到所有直接引入它的模块，再对每个结果跑go mod why -m 上一步结果 - 过滤测试干扰：加
grep -v '\.test\|/testdata\|/internal/test'，避免被测试工具污染路径判断 - 结合
go list -deps做交叉验证：go list -deps ./... | grep 'golang.org/x/net'只显示当前可构建路径下的真实依赖，比graph更贴近最终二进制 - 警惕版本分裂：同一库多个版本（如
v0.14.0和v0.17.0）同时存在，说明某处 require 冲突，得用replace或升级上游依赖统一版本
编译时怎么真正剔除未调用代码
Go 编译器默认做死代码消除（dead code elimination），但前提是函数/变量没被任何 reachable 路径调用。而 init()、反射、interface{} 类型擦除、或 _ "xxx" 匿名导入，都会让符号保留在二进制里。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用 CGO：
CGO_ENABLED=0 go build -ldflags="-s -w"，否则 libc、DNS 解析等动态依赖全打进二进制 - 确认没有
_ "net/http/pprof"这类调试包残留——它们虽不显式调用，但init()会注册 handler，导致整个net/http子树无法裁剪 - 避免用
reflect.Value.Call或unsafe直接操作函数指针，编译器无法静态分析调用链 - Go 1.22+ 默认开启更激进的裁剪，但如果用了
-gcflags="-l -N"关闭内联和优化，裁剪效果会大幅削弱
vendor 后还联网？三个必须检查的点
执行过 go mod vendor 不代表构建就离线，Go 仍可能去拉取模块——根本原因不是 vendor 目录本身，而是构建模式和模块解析逻辑没切过去。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 构建命令必须显式加
-mod=vendor：只写go build无效，正确写法是go build -mod=vendor - 确保当前目录是 module 根（含
go.mod），否则 Go 忽略vendor/并 fallback 到 GOPATH 或网络 - 加
-x参数观察真实行为：go build -mod=vendor -x，如果输出里出现git fetch或GET https://，说明某个依赖的go.mod文件缺失或校验失败，Go 自动回退联网
真正难处理的是那些带 //go:build ignore 或条件编译的模块——它们的 go.mod 可能没被 vendor 捕获，但又在特定 tag 下被 import，这种隐式依赖最容易漏检。
