go build会直接中断，因校验发现go.sum哈希与$gopath/pkg/mod中模块内容不一致；须先执行go clean -modcache清缓存、删go.sum，再用go mod tidy重建，避免代理污染或tag被覆盖导致问题复现。
go.sum校验失败时，go build会直接中断
错误信息里一定包含verifying github.com/xxx@v1.2.3: checksum mismatch，这不是网络超时或编译错误，而是Go在go build启动前就拦下了——它比对go.sum里存的哈希和本地$GOPATH/pkg/mod中实际解压的模块内容，不一致就拒绝继续。常见现象包括构建卡在“verifying”、VSCode里Ctrl+F5直接报错、CI流水线反复失败。
先清缓存，别删go.sum再跑tidy
手动删go.sum再go mod tidy看似快，但容易复现问题：旧缓存还在，新生成的哈希仍基于污染包。必须同步清理底层缓存：
- 运行
go clean -modcache——清空整个$GOPATH/pkg/mod，不是只删某几个子目录 - 删掉项目根目录下的
go.sum（推荐，避免残留干扰） - 执行
go mod tidy（不是go get -u），让Go按go.mod精确拉取并生成全新go.sum - 若项目用了
replace，确认它仍在go.mod中，否则tidy可能误换版本
代理污染比缓存损坏更难察觉
执行go clean -modcache后仍报checksum mismatch，大概率是代理返回了与官方不一致的zip包。验证方式很简单：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 临时禁用代理：
GOPROXY=direct go mod tidy（Linux/macOS）或set GOPROXY=direct && go mod tidy（Windows） - 若成功，说明代理有问题；可切换为
GOPROXY=https://goproxy.cn,direct或GOPROXY=https://proxy.golang.org,direct - 某些企业内网代理会重写zip包（比如注入header），此时
direct是唯一可信路径 -
GOSUMDB=off仅用于调试，不可长期开启——它等于放弃所有依赖完整性保护
作者force push了tag，只能用commit hash锁定
如果问题只集中在某个模块（如github.com/org/pkg@v1.2.3），且direct模式也失败，极可能是作者git push --force覆盖了该tag。此时go.sum里的哈希永远对不上新zip：
- 查当前tag实际指向：
go mod download -json github.com/org/pkg@v1.2.3，看输出中的Version和Info字段 - 改用commit hash拉取：
go get github.com/org/pkg@abcd123（不带v前缀） - 提交前确认
go.sum已更新且无warning——这是绕过被篡改tag的唯一稳妥方式
真正难的不是操作步骤，而是判断“是不是缓存的问题”：校验失败可能是缓存损坏、代理污染、tag被覆盖、甚至GOINSECURE配置不当导致私有模块悄悄退回到direct模式。每种情况触发条件不同，但修复路径都始于go clean -modcache，而不是盯着go.sum文件本身改来改去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
