go mod tidy 是唯一能准确识别冗余依赖的标准方式，它只删除既未被任何.go文件import语句引用、也未被其他已保留模块间接依赖的模块；需配合 -v 参数观察 removing unused 输出，并用 go mod why -m 验证真实依赖路径。
直接删 go.mod 里看着“不顺眼”的行，或盲目 rm -rf $GOPATH/pkg/mod，大概率导致构建失败、CI 炸锅、甚至线上二进制行为异常。真正安全的清理必须分层处理：先剔除代码中无引用的模块，再按需清本地缓存，最后确认运行时无副作用。
用 go mod tidy 删除未被 import 的模块
这是唯一能准确识别“冗余依赖”的标准方式——它只删两类：import 语句里完全没出现、且没被其他保留模块间接依赖的模块。
- 在项目根目录（含
go.mod）执行go mod tidy -v，观察输出里带removing unused的行，那是真正可删的 - 若某模块仅在
//go:build integration下才被 import，当前构建标签未启用时，tidy会误判为冗余，需手动加-tags=integration再跑一次 -
import _ "github.com/lib/pq"这类空白导入，若无 init 副作用且无传递依赖，也会被删；确认它是否注册了驱动（比如调用sql.Open("postgres", ...)） - 别信
go mod graph输出里的孤立节点——go mod why -m xxx才能验证是否真没被任何路径需要
用 go clean -modcache 清空已下载但不再需要的模块包
go mod tidy 不动磁盘上的 zip 和源码，go clean -modcache 才是清物理文件的命令，但它不是“一键瘦身”工具，而是配合 tidy 后的收尾动作。
- 执行前先跑
go list -m all | wc -l记下模块总数，tidy后再跑一次，下降明显再清缓存 -
go clean -modcache会删掉$GOPATH/pkg/mod下所有内容，包括校验文件（.ziphash），下次构建自动重下所需最小集合 - CI 环境建议每次构建前加这句，避免不同分支缓存污染；本地开发慎用，否则频繁重下拖慢迭代
- 如果只用了部分私有模块，可用
go mod graph | awk '{print $1}' | sort -u提取实际依赖域名，再手动删$GOPATH/pkg/mod/cache/download/下无关域名目录，比全清更精准
检查并清理残留的 vendor 目录和构建产物
go mod tidy 默认不碰 vendor/，而 vendor/ 本身若长期未更新，里面可能存着早已被 tidy 删掉的旧模块副本，变成隐蔽的冗余源。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 若项目已切回 module 模式（即没用
go build -mod=vendor），直接rm -rf vendor；否则先确认go env GOMOD输出是否指向当前go.mod - Docker 构建中常见错误：builder 阶段
RUN go mod download后没跟RUN rm -rf /go/pkg/mod/cache，导致缓存打进最终镜像 -
.git、testdata/、examples/这些目录不会被tidy或clean处理，但会增大镜像体积，必须靠.dockerignore排除 - 别在 Dockerfile 里写
RUN rm -rf .git—— 这只是新增一层“删操作”，实际体积没减，反而多存了元数据
验证清理是否真的生效
删完不验证，等于没删。尤其要注意反射加载、配置驱动、测试专用依赖这些 tidy 完全看不见的场景。
- 跑
go build ./和go test ./，重点看cmd/子目录和_test.go文件是否仍能编译通过 - 执行
go list -m -json all > deps.json，对比清理前后Indirect字段变化，确认传递依赖没被误砍 - 如果用了 JSON/YAML 配置动态加载模块（如插件机制），
go mod why查不到调用链，得靠运行时日志或 panic 堆栈反推 - 交叉编译环境（如
GOOS=linux GOARCH=arm64）下构建一次，确认没因缓存残留导致链接失败
最常被忽略的是：清理后没检查 go.sum 是否同步更新，或误删了被 //go:embed 引用但没显式 import 的资源模块——这些不会报错，但运行时文件缺失。
