sumdb 是 go 官方维护的不可篡改模块校验和日志，go get 卡住主因是客户端无法连接或验证 sumdb（如本地哈希与官方记录不一致、私有模块 404 等），而非单纯网络慢；需区分 goproxy（下载）与 gosumdb（校验）职责，优先用 sum.golang.google.cn 镜像或代理+校验双保底，禁用仅限可信私有场景。
SumDB 是什么，为什么 go get 会卡在 verifying github.com/xxx
SumDB 是 Go 官方维护的、不可篡改的模块校验和公开日志，go get 默认开启校验（GOSUMDB=sum.golang.org），每次下载模块前会查 SumDB 确认 go.sum 里记录的哈希是否被官方背书。卡住通常不是网络慢，而是客户端连不上 SumDB 或收到不一致响应——比如你本地 go.sum 里存的是旧哈希，但 SumDB 已记录该版本的新哈希（因作者重推 tag）。
- SumDB 不是缓存，也不存储源码，只存「模块路径 + 版本 + h1: 开头的校验和」三元组
- 它用 Merkle tree 实现可验证性：每个新条目都会改变根哈希，客户端可验证某条记录是否真实存在于历史中
- 国内直连
sum.golang.org常失败，但别急着关掉——关了等于放弃防投毒，只是要换更稳的接入方式
怎么让 go mod download 不报 checksum mismatch
错误信息通常是：verifying github.com/user/repo@v1.2.3: checksum mismatch。本质是本地 go.sum 记的哈希，跟 SumDB 当前公布的不一致。不是删 go.sum 就能解决，得先判断谁对。
- 运行
go mod download -json github.com/user/repo@v1.2.3，看输出里的Sum字段，这是 Go 工具链当前算出的哈希 - 手动查 SumDB：访问
https://sum.golang.org/lookup/github.com/user/repo@v1.2.3，对比返回的h1:xxx - 如果两者一致，说明你本地
go.sum被手改过或混入了脏数据，删掉该行再go mod tidy - 如果 SumDB 返回 404，说明该版本从未被官方索引过（常见于私有模块或刚打 tag 还没同步），此时需临时禁用校验：
GOSUMDB=off go mod download，但仅限可信源
国内环境下安全地绕过 SumDB 直连问题
直接设 GOSUMDB=off 风险高；设 GOSUMDB=sum.golang.google.cn 是官方镜像，但部分地区仍不稳定。更稳妥的做法是用代理+校验双保底。
- 优先配置
GOPROXY=https://goproxy.cn,direct，同时保留GOSUMDB=sum.golang.google.cn—— proxy 和 sumdb 是解耦的，proxy 负责下载，sumdb 负责校验 - 若
sum.golang.google.cn也超时，可切到GOSUMDB=off，但必须配合go mod verify定期检查：它会重新计算所有依赖的哈希并比对go.sum，发现不一致立刻报错 - CI 环境严禁关 SumDB，建议加一步
curl -sf https://sum.golang.org/ | head -c1健康检查，失败则中断构建
SumDB 对私有模块和 replace 的影响
SumDB 只收录公开模块（proxy.golang.org 能抓取到的）。私有仓库（如 gitlab 内网地址）、replace 指向本地路径或非标准域名的模块，不会进 SumDB，但 go mod 仍会尝试查——这就导致无意义的超时或 404。
立即学习“go语言免费学习笔记（深入）”；
-
replace后的模块，只要路径不是公开可索引的（例如replace example.com/foo => ./local-foo），SumDB 查询会被跳过，但go.sum仍会记录其本地计算的哈希 - 私有模块建议显式关 SumDB：
GOSUMDB=off，并在项目根目录放.netrc或配置git config认证，确保go mod download能走 ssh/HTTPS 拉代码 - 注意：
go list -m all输出的模块列表里，被replace掉的模块仍显示原始路径，但校验和来自替换目标——这点容易在排查checksum mismatch时误判源头
SumDB 的设计目标从来不是“快”，而是“可审计”。真正容易被忽略的，是它和 GOPROXY 的职责边界：proxy 解决下载，sumdb 解决信任，两者开关不能混为一谈。一个超时，不该直接废掉另一个。