go clean -modcache 是最直接有效的清理方式，它会删除 $gopath/pkg/mod（或 $gomodcache）下所有已下载的模块 zip 包、解压源码目录及 cache/download 中的 .info/.zip/.ziphash 文件，精准清除损坏依赖，但不触碰 go.mod、go.sum 和 vendor/。
go clean -modcache 是最直接有效的清理方式
它会删掉 $GOPATH/pkg/mod（或 $GOMODCACHE）下所有已下载的模块 zip 包、解压后的源码目录、以及 cache/download 里的 .info、.zip、.ziphash 文件。这些正是损坏依赖最常藏身的地方——比如校验失败但没被自动剔除的残缺 zip，或因网络中断写坏的 .info 文件。
执行后不会动你项目里的 go.mod、go.sum 或 vendor/，所以不用担心配置丢失。但要注意：下次 go build 或 go mod tidy 会重新下载所有依赖，首次构建变慢是正常现象。
- 运行前建议先备份当前项目的
go.mod和go.sum - 如果用私有代理（如 Nexus），确认
go env GOPROXY设置正确，否则重下时可能拉错源 - CI 环境中可放心加在构建脚本开头，避免跨构建缓存污染
哪些错误现象说明缓存真坏了？
不是所有依赖问题都要清缓存。只有出现以下典型表现，才大概率是本地模块包损坏：
-
go mod verify报错但go.sum没变，比如checksum mismatch for github.com/some/pkg@v1.2.3 -
go list -m all显示的版本和go.mod里写的不一致，且反复go mod tidy也刷不回来 - 执行
go get github.com/xxx/yyy@v1.0.0提示invalid version: unknown revision xxxxx，但远程 tag 确实存在 - 切换分支后
go build编译失败，错误指向某个包里根本不存在的函数，而该包在另一分支下能正常编译
只删特定模块比全清更省带宽
团队开发中，全量清缓存会让所有人重复下载，浪费带宽。更精细的做法是定位并删除“坏掉的”那个模块：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 先用
go list -m all | grep 'bad-module-name'确认模块路径和版本 - 进
$GOPATH/pkg/mod，找对应目录，比如github.com/bad-org/bad-pkg@v1.2.3 - 直接
rm -rf整个目录，再跑go mod download单独拉这个模块 - 对私有域名（如
git.internal.company.com），可批量清理：ls $GOPATH/pkg/mod/cache/download | grep internal，再筛出不用的老项目缓存
注意：手动删时别碰 cache/download 外的其他目录，尤其是 sumdb 或 proxy.golang.org 相关路径，它们负责校验逻辑，误删可能导致后续所有 go get 跳过 checksum 校验。
清理后验证是否真修复了
别只看命令执行成功就完事。关键要验证实际行为是否回归正常：
- 跑
go mod verify，确保无输出（即全部校验通过） - 用
go build -v ./...观察日志，每行以Fetching开头的地址是否是你预期的源（比如私有代理而非 proxy.golang.org） - 检查
go list -m -json all输出里，目标模块的Version和Replace字段是否与go.mod一致 - 如果之前报
unknown revision，现在go mod download -x应该能看到完整 fetch + unzip + verify 流程，而不是卡在某一步
真正容易被忽略的是：go clean -modcache 不解决 go.sum 本身被篡改的问题。如果怀疑 go.sum 有脏数据，得配合 go mod tidy -compat=1.18 或手动核对 checksum 行——缓存干净了，但签名文件错了，照样会校验失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
