go mod tidy 删不干净是因为它只删除既无 import 引用也无间接依赖的模块，无法识别反射调用、配置驱动加载、未启用构建标签的依赖、无副作用的空白导入及测试专用依赖，需结合 go mod why、go list 等命令人工验证。
go mod tidy 为什么删不干净
它只删两类模块：既没出现在任何 .go 文件的 import 语句里，也没被其他已保留模块间接依赖。但以下情况它完全看不见：
• reflect 动态调用的包（比如通过字符串加载 github.com/sirupsen/logrus）
• JSON/YAML 配置驱动的插件式加载（如 plugin 字段指定模块）
• 仅在 //go:build integration 下才启用的 import，而你当前构建没带这个 tag
• 空白导入 import _ "net/http/pprof" —— 如果没别的包依赖它，且它没注册 init() 副作用，就会被误删
• 测试专用依赖（go mod tidy -test 才会纳入分析）
怎么确认某个模块到底要不要得
别光看 go.mod 里有没有 require 行，用 go mod why 查真实路径：
• go mod why golang.org/x/sync → 看主模块是否真需要它
• go mod why -m golang.org/x/sync -test → 加 -test 才能暴露测试依赖
• 返回 (main module does not need module) 是安全可删信号
• 若路径含 vendor/ 或子目录下的 go.mod，说明是子模块显式 require，不能靠根目录 tidy 清理
• 运行 go list -m all | grep 包名，如果输出多行不同版本，说明存在版本分裂，得靠 replace 收敛
编译时哪些参数真正影响体积
本地构建精简二进制，必须同时满足三项：
• CGO_ENABLED=0：关掉 cgo，否则悄悄链接 libc，Alpine 镜像里体积虚高还可能运行失败
• -ldflags="-s -w"：必须一起用，-s 剥符号表，-w 去 DWARF 调试信息；单独用效果差，新版 Go 甚至报错
• -trimpath：去掉源码绝对路径，提升构建确定性，也微降体积
• 额外建议加 -buildmode=pie（仅限 Linux），但会略增体积，权衡安全性时再选
• 别信 upx —— 本地开发阶段没必要，CI 构建镜像时再考虑，且部分扫描工具会报可疑
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
清理后最容易漏掉的验证点
删完不跑这三步，等于白干：
• go build ./：确保所有 cmd/ 子目录下的 main 包都能编译，尤其注意交叉编译（GOOS=linux GOARCH=arm64 go build）是否仍正常
• go test ./：测试文件可能引入独立依赖，tidy 默认处理，但得确认没 break
• go list -m all | wc -l：对比前后数字，下降明显才说明真删了；再跑一次 go mod graph | wc -l，边数减少代表依赖图更干净
• 特别注意：如果用了 net/http 或 crypto/tls，证书解析器和 ASN.1 实现会自带进来，这时体积压缩天然受限，不是参数失效
立即学习“go语言免费学习笔记（深入）”；
