直接删缓存、重拉依赖可解决90%的checksum mismatch问题，因本质是本地校验状态与远程内容脱节；需执行go clean -modcache清缓存、删go.sum、再go mod tidy重建，必要时用goproxy=direct验证代理污染或改用commit hash锁定版本。
直接删缓存、重拉依赖，90% 的 checksum mismatch 问题当场解决。这不是网络不通，也不是代理配错，而是本地校验状态和远程内容脱节了——Go 的模块校验机制很严格，但也很“认死理”。
go clean -modcache 是第一反应动作
模块缓存（$GOPATH/pkg/mod/cache）一旦混入损坏包或旧版 zip，后续所有 go get、go mod tidy 都会复用它并反复校验失败。手动删子目录容易漏，整仓清理最稳：
- 运行
go clean -modcache—— 它不碰go.mod，也不删你写的代码 - 顺手删掉项目根目录的
go.sum（可选但推荐，避免旧哈希干扰重建） - 再跑
go mod tidy或go get -u github.com/xxx/yyy
验证 GOPROXY 是否返回污染包
国内常用镜像如 https://goproxy.cn 大部分时间可靠，但个别节点可能缓存了被作者 force-push 覆盖过的 tag，或同步滞后。临时绕过代理能快速定位是不是它的问题：
- Linux/macOS：执行
export GOPROXY=direct；Windows：执行set GOPROXY=direct - 再试一次
go get，如果成功，说明镜像源有问题 - 修复方式不是只换一个源，而是用逗号分隔多源 +
direct回退，例如：https://goproxy.cn,https://proxy.golang.org,direct - 注意：
direct必须写在末尾，且不能有空格或换行截断，否则私有模块（如git.internal.company）会直连失败
遇到作者改了 tag 却不升版本号，只能切 commit hash
这是最隐蔽的情况：有人把 v1.2.3 对应的代码库用 git push --force 覆盖了，而 Go 校验的是 zip 包哈希，内容一变就对不上。此时 go.sum 里存的是旧哈希，新 zip 已不可逆。
- 先看
go.sum里出问题那行，记下模块路径和版本 - 运行
go mod download -json github.com/xxx/yyy@v1.2.3，确认它实际指向哪个 commit - 如果发现 commit 已变，就放弃 tag，改用确定的 commit 锁定：
go get github.com/xxx/yyy@abcd123 - 别用
-insecure或关GOSUMDB，这会引入安全风险，尤其在 CI 环境
真正麻烦的从来不是报错本身，而是误判原因——比如把 checksum mismatch 当成网络问题去调代理，或以为删了 go.sum 就够了却忘了清缓存。校验机制是 Go 模块安全的基石，绕过去不如搞懂它怎么卡住的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
