go.sum中每行两个h1:值分别校验该模块go.mod文件内容和解压后整个源码目录的dirhash，前者防依赖声明篡改，后者防源码内容篡改，二者缺一不可。
go.sum 里两个 h1: 值分别校验什么
每一行 go.sum 记录实际包含两个哈希值，形如：golang.org/x/net v0.25.0 h1:abcd h1:efgh。这不是冗余，而是分层校验：
- 第一个
h1:abcd是该模块go.mod文件内容的校验和（带路径绑定）：Go 先对原始 UTF-8 字节做 SHA256，再拼上" go.mod\n"后二次哈希，防止把 A 模块的go.mod复制到 B 模块目录下冒充 - 第二个
h1:efgh是模块解压后整个源码目录的dirhash—— 不是简单 zip 哈希，而是 Go 官方定义的目录级哈希算法，按文件路径排序、逐个计算内容哈希后合并 - 两者缺一不可：改了依赖声明但没改代码，或改了代码但没改
go.mod，都会触发verified sum mismatch
GOSUMDB 如何用透明日志防篡改
GOSUMDB 不是“信任服务器返回的哈希”，而是要求服务器提供数学可验证的证明。核心靠透明日志（Transparent Log），本质是一棵默克尔树：
- 每个模块版本记录作为叶子节点；所有叶子两两哈希向上生成树根，根哈希公开且不可变
- 当你查询
github.com/some/pkg@v1.2.3时，sum.golang.org不只返回哈希，还返回从该叶子到树根的完整路径证明（Merkle inclusion proof） -
go命令本地重算这条路径，比对最终树根是否匹配已知权威根 —— 不匹配就拒绝，哪怕哈希本身看起来“合理” - 攻击者无法伪造证明：没有私钥就签不出合法路径，而私钥由 Go 团队严格保管
为什么不能跳过 GOSUMDB 直接信 go.sum
go.sum 本身不防首次污染（TOFU 问题），它只保证“后续一致”。常见误判场景：
- 你第一次
go get某个模块时，网络被中间人劫持，下载了恶意代码，go.sum就记下了这个坏哈希 —— 后续所有人拉这个 commit 都会“合法”通过 - 模块作者 force-push 覆盖 tag，旧哈希失效，但本地
go.sum还留着，go build会报错，但开发者可能直接删掉那行重试，反而绕过校验 -
GOSUMDB强制要求该哈希必须出现在全球公开日志中，且时间戳早于你首次下载 —— 伪造的日志条目无法通过时间一致性验证 - 关闭
GOSUMDB（如设为off）等于退回到 Go 1.11 之前的 TOFU 模型，企业级项目不应这么做
生产环境配置 GOSUMDB 的坑点
企业内网或合规场景常需自建或代理 GOSUMDB，但配置错误会导致静默失败：
立即学习“go语言免费学习笔记（深入）”；
- 设
GOSUMDB=proxy.example.com时，必须确保该服务实现了完整透明日志协议，不是简单 HTTP 转发 —— 否则返回的证明无效，go会 fallback 到sum.golang.org或直接报错 - 若用
GOSUMDB=off，go仍会写go.sum，但跳过远程背书；此时go.sum行末尾会标记为// indirect或缺失证明，CI 流水线应检测并拒绝 - 镜像站（如 goproxy.cn）不等于
GOSUMDB替代品：它们只缓存模块 zip，不提供日志证明，不能关掉GOSUMDB单靠镜像站保安全 - 调试时执行
go env -w GOSUMDB=off后忘记恢复，会导致后续所有新依赖都失去远程验证 —— 建议用GOENV文件或 shell wrapper 隔离临时配置
