Go 编译缓存目录异常膨胀如何安全清理

我遇到过几次 Go 项目把磁盘占满，第一反应都是去找一个“缓存目录”直接删掉。这个做法容易把构建缓存、测试缓存和模块下载缓存混在一起。更稳妥的答案是：先运行 go env GOCACHE GOMODCACHE GOPATH 确认实际目录，再优先使用 go clean -cache；只有确认问题来自测试、模块下载或 fuzz 数据时，才扩大清理范围。

官方文档：https://go.dev/cmd/go/

安全清理的关键不是记住一个固定路径，而是先确认 Go 当前使用的缓存对象，再用与问题范围相匹配的参数。

为什么编译缓存变大不等于模块缓存坏了

Go 的构建缓存默认放在当前系统的用户缓存目录下，也可以被 GOCACHE 改到自定义位置。模块缓存则由 GOMODCACHE 控制，未设置时通常落在 GOPATH/pkg/mod。两者都可能很大，但解决方式不同。

判断时可以先看这张对照表：

先确认真正占空间的目录，再决定清理范围

不要把网上常见的 ~/go、~/.cache/go-build 当成所有机器都一样的答案。自定义了 GOCACHE 或 GOMODCACHE 后，实际路径会变化；多工具链、多用户环境也可能让你看错目录。

# 先查看当前 Go 实际使用的缓存与模块目录，避免凭经验删除固定路径
go env GOCACHE GOMODCACHE GOPATH

# Unix-like 系统可只统计确认过的目录；Windows 可在资源管理器查看同一路径
du -sh "$(go env GOCACHE)" "$(go env GOMODCACHE)"

如果 GOCACHE 明显偏大，先处理构建缓存；如果 GOMODCACHE 才是主要占用，就要把重新下载依赖的网络和时间算进维护窗口。仅凭目录名字做判断，最容易把问题从“磁盘紧张”变成“下一次构建突然离线失败”。

四种清理命令分别会删掉什么

go clean 的参数是按对象划分的，不是同一个“清空缓存”按钮。日常编译缓存异常膨胀，通常从最小范围开始：

# 只清空 Go 构建缓存，模块下载内容不在这个范围内
go clean -cache

# 让构建缓存中的测试结果失效，下一次 go test 会重新执行
go clean -testcache

# 删除整个模块下载缓存，下一次需要时可能重新下载依赖
go clean -modcache

# 删除 fuzzing 使用的缓存；清理后历史覆盖输入可能需要重新积累
go clean -fuzzcache

这里有一个常见误区：go clean -testcache 不是删除所有构建产物，go clean -modcache 也不是“更彻底的 -cache”。它们服务的是不同对象。Go 文档还说明，构建缓存会周期性清理近期未使用的数据，所以普通项目没有必要按固定频率强制清空。

我的安全清理顺序：先小后大，最后再考虑重建

1. 先用 go env 记录路径和占用，确认不是别的工具或日志目录在增长。
2. 只针对构建缓存时运行 go clean -cache，清理后重新构建目标包。
3. 只有测试结果复用不符合预期时，才补充 go clean -testcache。
4. 确认模块下载缓存占用过大并且能接受重新下载时，再执行 go clean -modcache。
5. 清理后重新运行一次代表性构建或测试，确认依赖可获得、测试会真实执行，并把这次清理的范围记入维护记录。

我不建议直接对整个 GOPATH 做递归删除，也不建议把删除缓存写成无人确认的定时任务。缓存的价值就是减少重复工作；清理应当解决空间压力，而不是把每次构建都变成一次完整冷启动。

常见问题

执行 go clean -cache 会删除项目源码吗？

不会。它针对 Go 构建缓存，不等同于删除当前项目目录，也不会把模块源码目录当作构建缓存一起清掉。

为什么清理后第一次 go build 变慢？

构建缓存被清空后，编译结果需要重新生成；如果同时清理了模块缓存，还可能增加依赖下载时间。这是清理范围带来的恢复成本。

可以直接删除 GOMODCACHE 吗？

更建议使用 go clean -modcache，因为它表达的对象更明确。执行前确认网络、代理和离线依赖都满足下一次构建需要。

缓存会不会自己变小？

Go 会周期性删除近期未使用的构建缓存，但这不是立刻释放空间的承诺。遇到磁盘告警时，仍应先定位目录，再选择最小清理范围。