go mod verify 失败主因是本地环境与 sum.golang.org 的网络、时间（偏差＞5分钟）或配置（如非官方 proxy）不一致，导致校验和 mismatch；go.sum 每行含模块路径、版本及 h1: 开头的 zip 内容 SHA-256 校验和。
为什么 go mod verify 会失败？
模块签名验证失败，通常不是因为代码被恶意篡改，而是本地环境与 Go 模块代理（如 proxy.golang.org）或校验数据库（sum.golang.org）之间存在网络、时间或配置偏差。Go 默认启用模块签名验证（GOSUMDB=sum.golang.org），一旦校验和不匹配，go build 或 go get 就会中止并报错：verifying github.com/some/pkg@v1.2.3: checksum mismatch。
常见诱因包括：
- 本地修改了
go.sum文件但未同步更新依赖内容 - 使用了非官方 proxy（如私有镜像），但该 proxy 未正确转发
sum.golang.org的签名响应 - 系统时间偏差超过 5 分钟（
sum.golang.org使用时间戳签名，校验时严格比对） - 模块作者在打 tag 后又 force-push 修改了 commit，导致同一版本号对应不同代码
如何临时绕过签名验证（仅限调试）
绕过不是推荐做法，但在排查问题时有用。关键要区分场景：是跳过校验，还是禁用校验数据库？二者行为不同。
GOSUMDB=off 完全关闭签名验证，Go 仅比对本地 go.sum；而 GOSUMDB=direct 则跳过 sum.golang.org，直接从模块源（如 GitHub）下载并生成校验和——后者仍做完整性校验，但失去防篡改能力。
立即学习“go语言免费学习笔记（深入）”；
临时生效方式（建议只在 shell 会话中设置）：
GOSUMDB=off go build
或针对单次命令：
GO111MODULE=on GOSUMDB=off go get github.com/foo/bar@v1.0.0
注意：GOSUMDB=off 不影响 go.sum 文件的生成与更新，只是跳过远程签名比对。
go.sum 文件里每行代表什么？
每一行格式为：module path version/h1:hash，例如：
golang.org/x/text v0.14.0 h1:z6i1XJrLmQgYfFZ+KdVJxqyU9NQkO8TjwG78oMzW9bY=
其中 h1: 开头的字符串是基于模块 zip 内容计算的 SHA-256 校验和（经 base64 编码），不是 Git commit hash。它覆盖整个模块归档（含 .go 文件、go.mod、甚至隐藏文件），任何改动都会导致 hash 变化。
容易忽略的点：
- 同一模块不同版本（哪怕只改一行注释）必然产生不同
h1:值 - 如果模块没有
go.mod（即 legacy 模块），Go 会 fallback 到h12:（基于 GOPATH 模式下的目录结构哈希），这种 hash 更脆弱，易受本地构建环境影响 -
go.sum中可能包含// indirect行，表示该依赖未被直接 import，而是由其他模块引入——这类行同样参与校验
私有模块如何接入签名保护？
Go 官方 sum.golang.org 不索引私有仓库（如 GitHub 私有 repo、GitLab 内网实例），所以默认无法验证其签名。解决方案不是关闭校验，而是用 sum.golang.org 的兼容协议自建校验服务，或使用 GOSUMDB 指向支持 sumdb 协议的第三方服务（如 sum.golang.google.cn 在国内可用，但同样不支持私有模块）。
可行路径只有两条：
- 将私有模块发布到支持
sumdb的托管平台（如 pkg.go.dev 接入的公开镜像），前提是模块可公开 - 完全放弃远程签名验证，改用组织内可控机制：比如 CI 构建时固定
go.sum并提交，配合 git commit hash 锁定依赖来源，再通过内部审计流程保证 zip 内容一致性
硬编码 GOSUMDB 指向一个伪造的 sumdb 服务风险极高——Go 客户端会校验该服务的 TLS 证书及签名密钥，私自替换会导致 no public key for sum.golang.org 类错误。
真正难的不是技术实现，是让所有开发者理解：签名保护的价值不在“防止你改代码”，而在“确保所有人拉取的是同一个二进制等价物”。这点在跨团队协作或交付审计时才凸显出来。
