Go模块缓存路径由GOMODCACHE及其子目录cache/download共同构成，真实路径应通过go env GOMODCACHE确认；下载物（.zip/.mod/.info）存于GOMODCACHE/cache/download，解压源码存于GOMODCACHE根目录，清理必须用go clean -modcache以避免破坏校验状态。
Go 模块依赖下载的缓存路径不是单一目录，而是由 GOMODCACHE 和其子目录 cache/download 共同构成；手动删 $GOPATH/pkg/mod 看似清空，实则容易破坏校验状态，应优先用 go clean -modcache。
怎么确认当前模块缓存的真实路径
别猜，直接问 Go 工具链。运行命令获取的是实际生效路径，不是拼出来的默认值：
-
go env GOMODCACHE—— 输出的就是模块源码解压后存放的根目录（如/home/user/go/pkg/mod） -
go env GOPATH—— 仅用于推导默认GOMODCACHE，但不等于缓存本身 -
go env GOPROXY—— 影响GOMODCACHE/cache/download/下的 zip 来源，但不改变路径
常见错误：看到 $GOPATH/pkg/mod 就以为是“缓存目录”，其实它只是 GOMODCACHE 的默认值；如果设置了 GOMODCACHE，$GOPATH/pkg/mod 就完全失效。
模块下载物（zip/.mod/.info）到底存在哪
真正从网络拉下来的原始文件（含校验信息）不在 GOMODCACHE 根目录下，而是在它的子目录：GOMODCACHE/cache/download。
立即学习“go语言免费学习笔记（深入）”；
- 结构示例：
github.com/user/repo/@v/v1.2.3.zip、github.com/user/repo/@v/v1.2.3.mod、github.com/user/repo/@v/v1.2.3.info - 这些文件按 module@version 命名，版本不变就不会重复下载
- 解压后的源码（如
github.com/user/repo@v1.2.3-0.20230101000000-abcdef123456）才放在GOMODCACHE根目录下，通过符号链接指向 - 手动删
cache/download里的某个 zip，下次go mod download会重下；但删错.info可能导致invalid version错误
清理缓存时为什么不能直接 rm -rf $GOMODCACHE
因为 go 工具链在内部维护了索引和校验状态，硬删会留下脏数据，后续命令可能行为异常：
-
go list -m all可能报invalid version或漏掉本该存在的模块 -
go mod verify可能跳过校验或报 checksum mismatch - 符号链接失效，
replace或本地路径映射可能临时中断 -
go clean -modcache会同步清理GOMODCACHE和cache/download，并重置内部状态，这才是安全操作
注意：go clean -modcache 不影响 go.mod、go.sum、vendor/，也不动 $GOCACHE（编译缓存）。
多项目共用缓存时最常被忽略的并发与配额问题
默认所有项目共享同一个 GOMODCACHE，省空间但埋隐患：
- CI 流水线里多个 job 同时写
cache/download，可能因文件锁卡住，尤其挂载 NFS 或云盘时容易出现cannot lock - 本地开发十几个项目，
du -sh $GOMODCACHE超过 5GB 就该警惕——不是所有模块都还在用 - 企业级部署若用统一 NFS 存储，必须确认服务端支持
flock，否则并发go mod download会静默失败 - 临时方案：CI 中每个 job 设置独立
GOMODCACHE（如/tmp/go-mod-cache-$CI_JOB_ID），避免交叉污染
真正难处理的不是路径在哪，而是缓存状态是否一致、并发是否安全、清理后是否可重现——这些细节没对齐，go build 就可能在不同环境表现不一。
