这是 go 的安全机制，表明下载模块的 sha-256 哈希与 go.sum 中记录的不一致，说明依赖可能被篡改；常见于国内多代理源哈希不统一或 gosumdb 失效导致本地校验污染。
verifying github.com/xxx@v1.2.3: checksum mismatch 是什么
这不是网络超时或下载失败，而是 Go 在明确告诉你：「你这次下载的模块内容，和之前记录在 go.sum 里的指纹对不上」。它本质是一次安全拦截——Go 拒绝加载可能被篡改、劫持或污染的依赖。
错误信息里两行 h1: 开头的哈希值，分别是：
-
downloaded:本次从代理或源站实际拉下来的模块（go.mod或源码包）算出的 SHA-256 -
go.sum:项目里已提交的go.sum文件中存的旧哈希
只要二者不等，构建就中断。这不是 bug，是设计使然。
为什么国内环境特别容易触发这个报错
核心原因不是“网络慢”，而是多个可信源之间哈希不一致，常见于：
- 你在
go env -w GOPROXY=https://goproxy.cn下首次拉了模块，go.sum记下了goproxy.cn返回的内容哈希 - 后来切换到
https://mirrors.aliyun.com/goproxy，或没设GOPROXY直连 GitHub —— 同一版本模块，不同源返回的压缩包可能含额外文件、时间戳、或构建元数据差异，导致哈希不同 -
GOSUMDB=sum.golang.org默认启用，但国内 DNS 污染或防火墙导致请求卡在sum.golang.org/lookup/...，Go 工具链 fallback 到本地校验，而本地缓存又被不同代理污染过
注意：go clean -modcache 清掉的是本地缓存，但 go.sum 还在，下次拉包仍会比对失败。
怎么安全修复，而不是删 go.sum 了事
直接 rm go.sum && go mod tidy 看似快，但等于放弃所有依赖完整性保护——新生成的 go.sum 会记录当前代理下的哈希，换台机器、换次 CI 构建，又可能 mismatch。
- 先确认你用的
GOPROXY是否稳定且可信：推荐固定为https://goproxy.cn或https://proxy.golang.org,direct（后者对私有模块友好） - 运行
go env -w GOSUMDB=sum.golang.google.cn，把校验和数据库切到官方中国镜像，避免sum.golang.org访问失败导致 fallback 失效 - 执行
go clean -modcache清空本地缓存 - 再跑
go mod download，让 Go 重新从你指定的GOPROXY拉包并写入匹配的哈希到go.sum - 如果仍失败，检查
go.mod里有没有replace语句——本地 replace 的路径内容哈希和远程不一致，必然 mismatch
CI/CD 和团队协作时必须注意的点
很多团队在 CI 流水线里加了 GOSUMDB=off 来“绕过”问题，这是高危操作。一旦关掉，go.sum 就只剩个摆设，没人能保证依赖没被中间环节替换。
- CI 脚本里应显式设置
GOPROXY和GOSUMDB，和本地开发环境一致 -
go.mod和go.sum必须一起提交，缺一不可；go.sum不含敏感信息，体积小，无理由忽略 - 若项目用
go mod vendor，仍要保留go.sum——vendor 只解决分发，不替代校验 - 别在 Makefile 或脚本里自动执行
go mod tidy，除非你明确知道它会修改go.mod或go.sum
真正麻烦的从来不是报错本身，而是有人把它当成“构建失败”去 hack，而不是当成“安全告警”去溯源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
