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%\go\pkg\mod）。
最可靠的方式是直接查：
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:\go\modcache"
- 永久生效（推荐）：写入 shell 配置（
~/.zshrc或~/.bash_profile），**必须确保路径不含空格和中文**，否则go mod命令直接静默失败 - 验证是否生效：
go env GOMODCACHE
必须输出你设的路径，且ls $GOMODCACHE（或dir $env:GOMODCACHE）能列出内容
常见坑：
- 只改了
GOPATH没改GOMODCACHE，结果缓存还是跑到了新GOPATH下 ——GOMODCACHE会覆盖GOPATH的推导 - PowerShell 中用双引号包裹路径，但路径末尾多了反斜杠（
"D:\go\modcache\"），导致 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 构建效率的基石。频繁清理 ≠ 更干净，而是暴露了依赖管理或环境配置的问题。
