go clean -cache清$gocache中的.a编译中间产物，go clean -modcache清$gomodcache下的模块.zip、解压源码及校验文件；二者职责分明，混用会导致清理无效或构建失败。
清理 Go 模块缓存不是“删掉 pkg 就完事”，而是分清楚 go clean -cache 和 go clean -modcache 各管什么——前者清编译中间产物（.a 文件），后者清下载的模块源码（.zip 和解压目录）。混着清，要么白忙活，要么下次构建卡住。
go clean -modcache 清什么、什么时候必须清
go clean -modcache 删除的是 $GOMODCACHE（默认为 $GOPATH/pkg/mod）下所有模块的 .zip 包、解压后的源码目录、以及 cache/download 里的 .info 和 .ziphash 校验文件。它不碰 go.mod、go.sum，也不删 vendor/。
- 遇到
invalid version: unknown revision，但远程 tag 确实存在 → 很可能是本地.info文件没更新，缓存没同步最新 commit hash -
go list -m all显示的版本和go.mod里写的不一致，尤其在切分支或回退go.mod后 - 磁盘上
$GOPATH/pkg/mod占用超 10GB，而项目实际只依赖几十个模块 → 大概率是旧分支残留或私有代理缓存污染 - 启用了私有 GOPROXY（如 Nexus），却频繁报
checksum mismatch，且GOSUMDB是默认值 → 说明本地缓存校验数据和代理返回不匹配
go clean -cache 清什么、为什么有时清了没反应
go clean -cache 清的是 $GOCACHE（Linux 默认 $HOME/.cache/go-build）里的编译中间产物，主要是 .a 文件。这些文件让 go build 跳过重复编译，但一旦构建环境变动，就可能被错误复用。
- 切换
CGO_ENABLED=0和CGO_ENABLED=1后没清 → 链接阶段会静默失败，报undefined reference但不指明原因 - 改过 Cgo 代码后直接 build，逻辑没生效 → 旧
.a被复用，跳过了重新编译 - 执行
go clean -cache后磁盘空间没立刻释放 → 很可能 VS Code 或 GoLand 还在后台 hold 着缓存文件句柄；验证方式：lsof +D $(go env GOCACHE) | wc -l，输出为 0 才真空了 - 想立刻见效？先关 IDE，再跑
go build -a ./强制重编译，旧句柄自动释放
别乱删 $GOPATH/pkg，也别全量 rm -rf
现代 Go（1.10+）已把编译缓存移到 $GOCACHE，$GOPATH/pkg 现在基本只存 vendor 构建产物或 legacy 项目缓存。直接 rm -rf $GOPATH/pkg 可能破坏 go build -mod=vendor 的一致性。
-
go clean -i不是全局卸载命令：它只删当前目录下main包通过go install生成的二进制及其关联.a文件；你在cmd/mytool下装的mytool，跑到项目根目录执行go clean -i是无效的 - 只想删某个模块？手动更安全：
rm -rf $GOMODCACHE/github.com/xxx@v1.2.3和$GOMODCACHE/cache/download/github.com/xxx - CI 环境建议用
GOCACHE=$(mktemp -d)临时禁用缓存，构建完自动销毁，比清理更省事也更干净
真正容易被忽略的是缓存和进程句柄的耦合关系：Linux/macOS 下，go clean 删的是文件链接，空间释放取决于谁还开着文件。IDE、CI 脚本里未退出的 go build 进程，才是你清完缓存却看不见空间回收的元凶。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
