Go模块缓存在哪里_Go mod缓存目录说明

Go 模块缓存默认路径是 $GOPATH/pkg/mod，可通过 go env GOMODCACHE 确认；GOMODCACHE 优先级最高，未设置时 fallback 至此；手动修改该目录会导致校验失败、构建错误等，应使用 go clean -modcache 或 go mod tidy 管理。

Go 模块缓存默认在 $GOPATH/pkg/mod，不是 $GOCACHE，也不是 $GOPATH/src —— 混淆这三者是绝大多数人查错路径的根源。

如何确认当前模块缓存的真实路径

Go 不会凭空猜测路径，它严格按 环境变量 和规则推导：GOMODCACHE 优先级最高；未设置时 fallback 到 $GOPATH/pkg/mod；若连 GO 都没设，则用默认值（如 Linux/macOS 是 $HOME/go/pkg/mod，Windows 是 %USERPROFILE%gopkgmod）。

最可靠的方式是直接查：

go env GOMODCACHE

如果输出为空，再查：

go env GOPATH

然后拼出 $GOPATH/pkg/mod。别信“应该在这里”的直觉，go env 是唯一真相。

• 错误现象：执行 go mod download 后在 $GOCACHE/download 里翻半天，发现只有 .zip/.info 文件，没有源码 —— 因为那是下载中转区，不是模块工作区
• 错误现象：删了 $GOPATH/src 以为清了依赖，结果 go build 照常通过 —— 因为 src 在模块模式下已完全废弃，不存任何第三方包
• 注意：GOMODCACHE 是 Go 1.11+ 明确支持的环境变量，GOPATH 只是它的间接控制手段；改 GOPATH 会影响 bin 和 pkg，但改 GOMODCACHE 只动模块缓存，更干净

为什么不能手动修改 $GOPATH/pkg/mod 下的文件

这个目录由 Go 工具 链全自动维护，结构含版本后缀、校验文件、符号链接等，例如：github.com/sirupsen/logrus@v1.9.3。手动增删或重命名会导致：

• go mod verify 失败，报 checksum mismatch
• go build 找不到模块，提示 cannot find module providing package
• go list -m all 输出混乱，版本号错位

真正安全的操作只有两个：

• 用 go clean -modcache 彻底清空（适合 CI 或怀疑缓存损坏）
• 用 go mod tidy + go mod download 重建当前项目所需子集（适合日常维护）

想删某个旧版本？别进目录手删。先确认它是否被任何 go.mod 引用，再用 go mod graph | grep 过滤，否则删了可能让其他项目构建失败。

自定义缓存路径：临时 vs 永久，以及 Windows 注意点

改路径不是为了炫技，而是解决实际问题：比如系统盘空间小、多用户共享缓存、CI 环境隔离等。关键在写法严谨：

• Linux/macOS 临时生效：

  export GOMODCACHE="/data/gomod"

• Windows PowerShell 临时生效：

  $env:GOMODCACHE = "D:gomodcache"

• 永久生效（推荐）：写入 shell 配置（~/.zshrc 或 ~/.bash_profile），** 必须确保路径不含空格和中文 **，否则 go mod 命令直接静默失败
• 验证是否生效：

  go env GOMODCACHE

  必须输出你设的路径，且 ls $GOMODCACHE（或 dir $env:GOMODCACHE）能列出内容

常见坑：

• 只改了 GOPATH 没改 GOMODCACHE，结果缓存还是跑到了新 GOPATH 下 —— GOMODCACHE 会覆盖 GOPATH 的推导
• PowerShell 中用双引号包裹路径，但路径末尾多了反斜杠（"D:gomodcache"），导致 Go 解析失败
• 容器环境里挂载了缓存目录，但权限是 root，而构建用户是 non-root，导致 go mod download 报 permission denied

清理缓存前必做的三件事

go clean -modcache 是把双刃剑：快、彻底，但也意味着下次 go build 要重下所有依赖（可能几百 MB）。执行前务必确认：

• 当前网络稳定，尤其用了 GOPROXY（如 https://goproxy.cn）且能访问
• 项目 go.sum 已提交，避免清理后拉取到被篡改的恶意模块
• 没有正在运行的 go 进程（如 go run、IDE 的 Go 插件后台任务），否则可能触发文件占用错误

替代方案更温和：

• 只清理下载缓存（保留 解压 源码）：

  rm -rf $GOMODCACHE/cache/download

• 统计空间占用，针对性处理大模块：

  du -sh $GOMODCACHE/* | sort -hr | head -20

• 用 go mod vendor 把依赖锁定到项目内，之后可完全绕过模块缓存（适合离线构建）

最后提醒一句：模块缓存不是垃圾，而是 Go 构建效率的基石。频繁清理 ≠ 更干净，而是暴露了依赖管理或环境配置的问题。