根本原因是go.sum哈希与pkg/mod/cache中实际模块内容不匹配，go强制校验失败即中断；必须按顺序清空download、sumdb、vcs三层缓存，再设goproxy=direct验证，否则残留缓存会重建损坏状态。
为什么 go build 突然报 “checksum mismatch” 却删不干净？
根本原因不是缓存本身坏了，而是 go.sum 记录的哈希值和本地 pkg/mod/cache 里实际解压后的模块内容对不上——Go 不会自动修复或跳过校验，只要校验失败就直接中断构建。手动删 vendor 或重跑 go mod tidy 都无效，因为问题在模块缓存层，不在项目目录。
必须清空的三个位置及其顺序不能错
Go 模块缓存分三层：全局下载缓存、解压后模块快照、本地校验记录。只删其中一两个，下次 go build 还会从残留部分重建损坏状态。
-
rm -rf $GOPATH/pkg/mod/cache/download—— 清掉原始 zip 包，防止重用坏包 -
rm -rf $GOPATH/pkg/mod/cache/download/sumdb—— 删除校验数据库缓存（sum.golang.org的本地镜像），否则仍会拿旧哈希比对 -
rm -rf $GOPATH/pkg/mod/cache/vcs—— 清掉 Git/SVN 等 VCS 克隆缓存，避免拉取时复用已损坏的 commit 快照
注意：$GOPATH/pkg/mod 目录本身不用删（里面是符号链接和模块软引用），删了反而导致 go mod download 重复解压。
GO111MODULE=on 下仍卡在 checksum mismatch 怎么办？
即使启用了模块模式，Go 仍可能回退到 GOPROXY 默认值（如 https://proxy.golang.org）并缓存坏响应。临时绕过代理强制直连能暴露真实问题：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 运行
export GOPROXY=direct（Linux/macOS）或set GOPROXY=direct（Windows） - 再执行
go clean -modcache—— 这个命令等价于清空$GOPATH/pkg/mod，但会同时清理关联的校验状态 - 最后跑
go mod download，观察是否出现明确的网络错误（比如证书问题、DNS污染），而不是模糊的 checksum mismatch
如果直连成功但 proxy 失败，说明是代理节点缓存了损坏包，需换代理或等其刷新。
如何验证缓存真清干净了？
别只看目录是否为空。真正有效的验证方式是：
- 检查
go env GOCACHE和go env GOPATH输出，确认路径没被覆盖或指向意外位置 - 运行
go list -m all | head -n 3，如果首次输出含大量cannot load或unknown revision，说明缓存已重置；若仍快速列出模块名，大概率还有残留 - 触发一次真实构建：
go build -x ./...，观察日志里是否出现unzip、download、verify等动词——有这些动作才代表从头拉取校验
最隐蔽的坑是 IDE（如 GoLand）自带模块缓存或后台 go list 进程锁住了文件，关掉 IDE 再操作往往能解决“删了又回来”的现象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
