Go 的 pkg 目录变大主因是 $GOCACHE（1.10+ 默认）和 $GOPATH/pkg/mod 缓存积累，尤其分支切换、依赖升级、交叉编译后旧缓存不自动清理；安全清理应优先用 go clean -cache 和 go clean -modcache，而非手动 rm -rf。
Go 的 pkg 目录为什么越用越大？
因为 Go 在构建时会把编译后的中间产物（主要是 .a 归档文件）缓存在 $GOPATH/pkg 或 $GOCACHE（1.10+ 默认启用），尤其是频繁切换分支、升级依赖、交叉编译后，旧版本的缓存不会自动清理。这些文件不参与运行，但可能占几个 GB —— 你删掉它们，下次构建会慢一点，但完全不影响代码正确性。
怎么安全清空 Go 缓存？别只删 pkg
只手动删 $GOPATH/pkg 是过时做法，现代 Go（1.10+）默认走 $GOCACHE，而 pkg 目录本身现在主要存 vendor 化或 legacy 构建产物。真正该清的是 GOCACHE：
-
go clean -cache：清空$GOCACHE，推荐首选，安全且知道删什么 -
go clean -modcache：清空$GOPATH/pkg/mod（即 Go Modules 下载的源码缓存），适合模块依赖膨胀后使用 - 不要直接
rm -rf $GOPATH/pkg：可能残留锁文件或破坏 vendor 构建一致性 - 检查路径：
go env GOCACHE和go env GOPATH，确认你删的是对的地方
go clean 不起作用？可能是没触发缓存重建条件
go clean -cache 只删缓存，不重置构建状态；如果之后 go build 没重新编译（比如文件没改、或用了 -a 以外的默认行为），你会误以为“没清干净”。实际表现是磁盘空间没立刻释放——因为：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Linux 下已打开的缓存文件被进程占用时，
rm后空间不会立即归还，需等构建进程退出 - 某些 IDE（如 VS Code + Go extension）后台静默构建，会立刻重建部分缓存
-
go build -a强制全部重编译，才能真实验证缓存是否清空
长期节省空间：关掉不需要的构建缓存
不是所有项目都需要完整缓存。比如 CI 环境、临时调试机，可以禁用 GOCACHE 避免堆积：
立即学习“go语言免费学习笔记（深入）”；
- 临时禁用：
GOCACHE=off go build - 彻底关闭：
go env -w GOCACHE=off（注意：后续每次构建都会变慢） - Modules 缓存无法完全关，但可限制大小：
go env -w GOMODCACHE=$HOME/go/pkg/mod+ 定期go clean -modcache - 交叉编译产物最占空间（
linux/amd64,darwin/arm64等各一份），如无多平台需求，避免无意义的GOOS/GOARCH切换
缓存目录不是黑盒，但也不是随便 rm -rf 的地方；看清 go env 输出的实际路径，分清 GOCACHE 和 pkg/mod 的职责，比背命令重要得多。
