go clean -modcache 是修复 checksum mismatch 的必要止损操作，它清除模块缓存中损坏的 zip、源码及校验文件，但保留 go.mod、go.sum 和 vendor/；执行前需确保 GO111MODULE=on，清理后可通过 go build -v 验证拉取路径。
遇到 checksum mismatch 时，go clean -modcache 是最直接的修复动作
这不是“优雅”，而是必要止损。当 go build 或 go mod verify 报 checksum mismatch，且确认 go.sum 没被手动改过、私有代理配置正确，基本就是缓存里的 zip 或解压源码被破坏或混入了不同来源的同版本包。
-
go clean -modcache会删掉$GOMODCACHE（默认$GOPATH/pkg/mod）下所有模块源码、.zip包和cache/download中的校验文件（.info、.ziphash） - 它不碰
go.mod、go.sum和vendor/，所以项目定义不受影响 - 执行前必须确保
GO111MODULE=on，否则命令静默无效 - 清理后首次
go build -v能看到每行开头的Fetching，可验证拉取地址是否符合预期（比如是否走了私有代理）
只想删某个损坏模块？别全清，rm -rf 手动删更精准
全量清理在 CI 或多人共享开发机上容易引发重复下载带宽浪费。若已定位到具体模块（比如 github.com/badpkg/foo@v1.2.3），直接删对应路径即可：
- 删解压源码：
rm -rf $GOMODCACHE/github.com/badpkg/foo@v1.2.3 - 删原始 zip 和校验数据：
rm -rf $GOMODCACHE/cache/download/github.com/badpkg/foo - 删完立刻跑
go mod verify，确认后续下载内容与go.sum一致 - 注意：路径中的
@v1.2.3是精确版本，不能漏；模块名大小写、斜杠方向要和go list -m all输出完全一致
go mod tidy 不是清理缓存的命令，但它能帮你识别“该删谁”
go mod tidy 的作用是同步 go.mod 和实际 import，它本身不删磁盘文件，但能暴露冗余依赖：
- 运行
go mod tidy -v，观察哪些模块被“dropped”——这些就是当前项目不再需要的 - 再用
go list -m all | grep 'indirect'看间接依赖，结合go mod why -m github.com/xxx判断是否真无用 - 确认无用后，手动删
$GOMODCACHE下对应目录，比全清-modcache更轻量 - 别指望
go mod tidy自动清理磁盘——它只管go.mod和go.sum，pkg/mod里的文件得你动手
真正容易被忽略的点：缓存损坏常和 GOSUMDB 配置冲突有关
很多 checksum mismatch 并非文件损坏，而是本地缓存校验数据和代理返回不匹配。比如启用了 Nexus 私有代理，但 GOSUMDB 还是默认的 sum.golang.org，就会导致校验失败。
- 检查当前值：
go env GOSUMDB，私有环境应设为off或指向内部 sumdb - 若用
off，需确保go env GOPRIVATE已包含所有私有域名，否则go get可能跳过校验拉错版本 - 清理前先备份
go.sum和go list -m -json all > deps.json，避免重下时混淆来源
