go mod tidy 能删掉未被当前构建环境 import 的模块，但仅限于启用构建标签下可见的 import；它不识别 //go:embed、//go:generate、测试文件（除非显式运行 go test）及反射调用等隐式依赖，需人工验证。
go mod tidy 能不能直接删掉所有没 import 的模块
能，但只删「当前构建环境能看见的」那些。它扫描所有 .go 文件，按启用的构建标签（GOOS/GOARCH///go:build）决定哪些 import 有效。常见漏删场景：
– 模块只在 //go:embed 或 //go:generate 中出现 → 不算 import，会被删
– 测试文件（*_test.go）里的依赖，默认不参与 tidy 分析，除非你运行 go test ./ 前先执行 go mod tidy -compat=1.21 并确保环境一致
– 空导入（import _ "github.com/lib/pq"）会被保留，因它仍属显式声明
如何识别哪些项目真正“不活跃”再动手
别靠目录名或 git log 判断。真实依据是：近期没有构建成功、没跑过测试、且 go list -m all 输出里大量模块带 // indirect 但无任何调用路径。实操建议：
– 先进每个项目根目录，运行 go list -m -json all | jq 'select(.Indirect == true) | .Path' 提取纯间接依赖列表
– 对每个间接模块，执行 go mod why -m github.com/some/pkg；返回 main module does not need module 才算安全
– 若输出含 vendor/ 或 internal/ 子路径，说明有子模块显式 require，不能仅在根目录 tidy
批量清理时怎么避免把私有模块拉错版本
关键不是删，而是删完后首次构建不崩。必须提前确认：
– go env GOPRIVATE 已设为你的私有域名（如 git.internal.company.com），否则 go clean -modcache 后 go build 可能跳过校验去拉 public proxy 的假包
– 清理前备份 go.sum 和 go.mod，并用 go list -m -json all > deps.json 记录精确依赖快照
– 执行 go clean -modcache 后，首次 go build -v ./ 时观察每行开头的 Fetching 地址，确认私有模块走的是你配置的代理或直连，而非 proxy.golang.org
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
磁盘空间吃紧时，只清不用的模块比全清更稳妥
全量 go clean -modcache 在 CI 或多项目共享 GOPATH 时会引发重复下载风暴。更细粒度做法：
– 运行 go mod graph | awk '{print $1}' | sort -u > used_modules.txt 获取当前项目实际引用的所有模块名
– 对比 ls $GOPATH/pkg/mod/cache/download/ 下的域名目录，手动删掉不在 used_modules.txt 里的私有域名缓存（例如已下线的老项目 git.old.company.com）
– 公共模块留着，定期用 go mod tidy -v 配合 go mod download -json 查未被引用的版本，再针对性 rm -rf $GOPATH/pkg/mod/cache/download/github.com/@v/vX.Y.Z
立即学习“go语言免费学习笔记（深入）”；
真正容易被忽略的点是：go mod tidy 不处理 vendor 目录，go clean -modcache 也不动它。如果项目之前执行过 go mod vendor，清理完依赖后必须手动删掉旧 vendor/ 再重跑 go mod vendor，否则会出现本地有包但 go.mod 没声明的不一致状态。 
