Go go env GOMODCACHE 怎样确认模块缓存目录

我遇到过一次很典型的 Go 环境问题：机器的磁盘占用持续上升，项目却没有变大；换了构建目录后，又发现依赖似乎“还在原来的地方”。先记住结论：go env GOMODCACHE 输出的就是当前 Go 命令真正使用的模块缓存目录。没有单独设置时，它通常是第一个 GOPATH 下的 pkg/mod，而且它和编译产物使用的构建缓存不是一回事。

本文只围绕目录确认、配置核对和安全清理展开。模块缓存通常由多个 Go 项目共享，不能把当前项目目录大小直接当成依赖缓存大小。

先用 go env GOMODCACHE 看到真实目录

不要先猜用户目录，也不要只看 shell 里有没有同名变量。让 go 命令自己输出生效值最稳妥：

# 读取当前 Go 命令实际采用的模块缓存目录
go env GOMODCACHE

# 同时查看 GOPATH，便于理解未自定义时的默认关系
go env GOPATH

Go 官方文档把模块缓存定义为保存已下载模块文件的目录；如果没有设置 GOMODCACHE，默认位置是 $GOPATH/pkg/mod。因此，第一条命令比手动拼接路径更可靠：它已经替你处理了当前环境和 Go 配置文件中的生效值。

如果只是想检查某个依赖是否进入缓存，可以再查看模块列表，但不要把这一步误认为“重新下载”。模块缓存中的内容可能被多个项目复用。

为什么看到的目录和预期不一样

最常见的误会是把四类目录混在一起：模块缓存保存下载的模块文件，构建缓存保存编译包和其他构建产物，vendor 是项目树里复制出来的依赖，项目源码则由自己的工作区管理。

这几个目录的清理动作也不同。go clean -modcache 针对整个模块缓存；go clean -cache 针对构建缓存；启用 vendor 时，构建命令可能直接从项目的 vendor 目录读取依赖。只因为构建命中了缓存，就不能推断模块缓存为空。

另一个原因是配置来源不同。你在当前 shell 中临时设置了 GOMODCACHE，或者通过 go env -w 写入了持久配置，都会让最终路径与“默认路径”不同。排查时应同时看“环境里写了什么”和“go 命令最终采用什么”。

迁移模块缓存时，先确认配置是否真的生效

如果团队希望把模块缓存放到独立磁盘，可以先用持久配置，再重新读取确认：

# 将模块缓存位置写入 Go 的持久环境配置
# 目录应提前准备好，并确保当前用户具备访问权限
go env -w GOMODCACHE=/data/go/pkg/mod

# 重新读取生效值，确认写入结果
go env GOMODCACHE

# 取消持久配置，恢复由 GOPATH/pkg/mod 推导的默认关系
go env -u GOMODCACHE

不要只编辑某个项目的 .env 文件后就认为所有 Go 命令都会使用新目录；命令是否继承该环境，取决于启动它的进程。也不要把迁移后的空目录误判为“下载失败”，模块文件只有在命令实际需要并成功获取后才会出现在缓存中。

在 CI 中，建议把 go env GOMODCACHE 当成日志里的一个明确字段，同时记录 go env GOPATH。这样换 runner、换用户或切换镜像后，目录变化能被直接解释。

清理前后的核对清单

官方文档说明模块缓存没有自动大小上限，Go 也不会主动移除其中内容，所以磁盘增长并不奇怪。清理前先记下 go env GOMODCACHE 的输出；如果只是想释放编译产物空间，不要误删模块缓存。

常见问题

GOMODCACHE 没设置时，为什么还能读出路径？

因为 Go 会回退到默认关系：第一个 GOPATH 目录下的 pkg/mod。go env GOMODCACHE 展示的是解析后的结果，不要求你显式写过 GOMODCACHE。

模块缓存和 GOCACHE 可以放在同一个目录吗？

技术上可以分别配置，但不建议人为混放。两者保存的对象和清理命令不同，分开更容易计算空间、设置权限并定位 CI 缓存命中问题。

为什么删除模块缓存后，项目还能继续编译？

可能是项目启用了 vendor，也可能是当前构建使用了其他缓存或尚未触发需要重新下载的路径。先分别读取模块缓存、构建缓存和模块模式，再判断结果。