go.sum不是锁文件，而是校验快照；它仅记录模块内容sha-256哈希用于完整性校验，不参与版本选择，校验失败时中断构建，必须提交至git且不可手动编辑。
go.sum 不是锁文件，而是校验快照
很多人误以为 go.sum 是类似 package-lock.json 的“版本锁定”文件，其实它只存哈希，不控制版本选择。每次 go mod download 或 go build 时，Go 都会重新计算模块内容的 SHA-256 哈希（基于所有 Go 源文件 + go.mod），再和 go.sum 里对应行比对。不一致就报 verifying ...: checksum mismatch，直接中断。
关键点：
-
go.sum里每行格式固定：模块路径、版本、空格、h1:开头的哈希（如github.com/some/pkg v1.2.3 h1:abc...），手改一个字符就失效 - 同一模块不同版本必然哈希不同；同一版本在任何机器上生成的哈希完全一致
- 它记录的是“首次成功下载时的内容指纹”，不是“权威源承诺的内容”——这就是 TOFU（首次使用即信任）的脆弱点
GOSUMDB 如何打破 TOFU 困境
TOFU 的问题是：第一次拉包时没人验证，恶意包可能被悄悄写进 go.sum。GOSUMDB 的作用就是让这“第一次”也经过公证。它不是简单查个哈希表，而是用透明日志（Transparent Log）+ 默克尔树做密码学证明。
实际流程：
- 你执行
go get github.com/some/pkg@v1.2.3，Go 先算出本地下载内容的哈希 - 然后向
GOSUMDB（默认sum.golang.org）发起查询：/lookup/github.com/some/pkg@v1.2.3 - 服务器返回哈希值 + 该条目在默克尔树中的路径证明（inclusion proof）
- Go 客户端用硬编码的公钥验证签名，并用证明重建树根哈希，确认该哈希确实被写入过全局日志——不是服务器临时编的
- 只有验证通过，才把哈希写进
go.sum；后续构建只比对本地哈希，但源头已被日志锚定
国内常见校验失败，90% 是网络链路被干扰
报错如 fetching sum.golang.org/lookup/...: 403 或 invalid GOSUMDB: malformed verifier id，基本不是模块问题，而是请求卡在中间环节。
典型原因和应对：
- DNS 污染导致
sum.golang.org解析到错误 IP——优先设镜像：go env -w GOSUMDB=sum.golang.google.cn - 企业防火墙拦截或重写 HTTPS 响应——检查是否误配了
GOINSECURE或代理规则覆盖了sum.golang.org -
GOPROXY配成https://goproxy.io,direct后，sum.golang.org请求也被 proxy 转发（它不接受代理）——应确保GOPROXY的direct分支生效 - 别轻易设
GOSUMDB=off：这等于放弃所有远程校验，go.sum变成“信谁谁说了算”，CI 构建风险陡增
自建 sumdb 镜像？官方根本不允许
网上有些文章说“搭建内网 sumdb”，这是误导。Go 工具链只信任 Go 团队私钥签名的响应，公钥已硬编码在 cmd/go 源码里。你搭个 HTTP 服务返回哈希，客户端根本不会验签，直接拒绝。
真正可行的内网方案只有两种：
- 离线模式：
GOSUMDB=off+ 人工审计go.sum+ 定期用go mod verify对比公共日志（需能连外网） - 申请 Go 团队授权使用其签名密钥（几乎不开放）
所谓“自建 sumdb”通常只是缓存代理（如 Athens），它不提供校验和，只加速下载；最终校验仍需回源 sum.golang.org。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
