go clean -modcache 删除 $GOMODCACHE 目录下所有模块的 .zip 包、解压源码目录及校验文件（.info/.ziphash），不删除 go.mod、go.sum 和 vendor/；需确认 GO111MODULE=on、GOMODCACHE 路径及磁盘必要性。
go clean -modcache 到底清什么
它删的是 $GOMODCACHE 目录下的全部内容：所有模块的 .zip 包、解压后的源码目录（如 github.com/sirupsen/logrus@v1.14.0）、校验文件（cache/download/ 下的 .info 和 .ziphash）。不碰 go.mod、go.sum，也不动 vendor/。你项目里写的依赖声明没丢，只是本地“货仓”被清空了。
执行前必须确认的三件事
-
GO111MODULE=on—— 否则go clean -modcache静默失败，命令跑完但啥也没删 - 运行
go env GOMODCACHE确认路径，常见是$GOPATH/pkg/mod，不是$GOPATH/src - 磁盘空间真紧张？先看占用：
du -sh $(go env GOMODCACHE)，若不到 1GB 且没遇到checksum mismatch或cannot find module，别乱清
为什么有时清了还是报错
常见现象包括 go list -m all 显示版本和 go.mod 对不上、go mod verify 失败但 go.sum 没改。原因往往是：
- 私有模块代理切换后，缓存里混着不同来源的同版本包（比如之前走
proxy.golang.org，现在走公司 Nexus） - 手动改过
$GOMODCACHE里的源码，go build仍会用，直到下次go mod download覆盖 - 清理后没立刻跑
go mod verify，导致后续拉取的模块和go.sum校验不一致
不想全清，只想删某个模块
直接删更安全，避免全量重下浪费带宽：
- 删模块源码：
rm -rf $(go env GOMODCACHE)/github.com/xxx@v1.2.3 - 删对应 zip 和校验数据：
rm -rf $(go env GOMODCACHE)/cache/download/github.com/xxx - 删完建议立即执行
go mod download github.com/xxx@v1.2.3，验证能否正常拉取
真正容易被忽略的是：清理后首次 go build 会触发完整重下，此时如果网络不稳定或私有仓库权限失效，错误会被误判为“缓存没清干净”，其实问题在拉取环节，不在缓存本身。
