go mod verify 报 checksum mismatch 错误的根本原因是本地缓存模块目录被手动修改（如改源码、touch 文件等），导致校验和与原始 zip 不一致；应精准删除对应模块解压目录并重下载，而非仅清空整个 modcache 或删除 go.sum。
go mod verify 报 checksum mismatch 错误
这是最典型的症状：执行 go mod verify 或 go build 时提示类似 github.com/some/pkg: checksum mismatch，后面跟着本地缓存的校验和与预期值不一致。根本原因不是网络或代理问题，而是你本地 pkg/mod/cache 下某个模块的解压目录被手动修改过（比如加了 debug print、改了源码、甚至只是 touch 了一个文件），导致 Go 计算出的校验和变了。
如何定位被污染的模块目录
Go 不会告诉你具体哪个文件被改了，但能指出模块路径和版本。先看报错里的模块名和版本号，例如：golang.org/x/net v0.25.0。然后去缓存目录找对应路径：
-
$GOPATH/pkg/mod/cache/download/golang.org/x/net/@v/v0.25.0.info—— 里面记录了官方校验和 -
$GOPATH/pkg/mod/cache/download/golang.org/x/net/@v/v0.25.0.zip—— 原始 zip 包 -
$GOPATH/pkg/mod/golang.org/x/net@v0.25.0/—— 解压后的实际工作目录（这个就是被改过的）
直接对比 .zip 解压出来的原始内容和当前 @v0.25.0/ 目录的 go.sum 记录值，就能确认是否被篡改。更简单的方法是删掉整个 @v0.25.0/ 目录，让 Go 下次自动重解压。
安全清理并重建模块缓存
不要只删 go.sum 或只 go clean -modcache —— 后者会清空全部缓存，浪费带宽；前者完全没用。正确做法是精准清理 + 强制重拉：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 删掉对应模块的解压目录：
rm -rf $GOPATH/pkg/mod/golang.org/x/net@v0.25.0 - 删掉它的下载缓存（可选，避免用旧 zip）：
rm $GOPATH/pkg/mod/cache/download/golang.org/x/net/@v/v0.25.0.* - 运行
go mod download golang.org/x/net@v0.25.0，强制重新下载并解压 - 再跑
go mod verify，应该通过
注意：如果项目里用了 replace 指向本地路径，那 go mod verify 本来就会失败——它只校验远程模块。这种情况下，verify 本就不该用，或者得先注释掉 replace 再验证。
为什么 go.sum 不会自动更新
go.sum 是只写不修的记录文件。Go 在首次下载模块时把校验和写进去，之后每次校验都严格比对。它不会因为本地文件被改就自动重算并覆盖 go.sum —— 那会破坏完整性保证。所以一旦发现 mismatch，说明要么模块源被篡改（危险），要么你本地动了它（开发调试常见）。后者只要清理缓存重拉就行，前者得立刻检查是否遭恶意注入。
真正容易被忽略的是：IDE（如 VS Code 的 Go 插件）有时会在后台悄悄打开并保存模块文件，哪怕你没主动编辑，也可能触发时间戳变更或格式化，导致校验失败。建议把 $GOPATH/pkg/mod 设为只读，或在 shell 中 alias go 命令加 -mod=readonly 参数来防误改。
