go.sum中h1:开头的哈希用于校验模块内容完整性，而非锁定版本；它记录模块ZIP包（含所有.go文件）和/go.mod文件的SHA-256哈希值，构建时重新计算比对，不一致则报verified sum mismatch并中断构建。
go.sum 里那一长串 h1: 开头的哈希是干啥的
它不是“锁版本”，而是“验指纹”——每次 go mod download 或构建时，Go 会重新计算模块 ZIP 内容（所有 Go 源文件 + go.mod）的 SHA-256 哈希，再跟 go.sum 里记录的比对。不一致就直接报错：verified sum mismatch，中断构建。
常见误解是以为哈希对应“某个 commit”或“某个 tag”，其实它只认内容：哪怕你 fork 了同一个仓库、改了一行注释再打 v1.2.3 tag，哈希也完全不同。
-
h1:开头的是模块整体内容哈希（含源码 +go.mod） -
/go.mod后缀那行是单独对依赖模块自身的go.mod文件算的哈希，用于快速解析依赖树，不用下载整个包 - 同一模块不同版本必然哈希不同；同一版本在不同机器上生成的哈希完全一致
为什么 go.sum 会自动多出 /go.mod 这一行
这是 Go 工具链为优化依赖解析做的预处理。当你项目依赖 A，而 A 又依赖 B，Go 在构建前需要知道 B 的版本范围——但不需要立刻下载 B 的全部代码，只要拿到它的 go.mod 就够了。
所以 go.sum 里每条 /go.mod 记录，本质是缓存了间接依赖的元信息哈希，让 go mod graph 或 go list -m all 能快速推导依赖图，而不必反复拉取完整模块。
- 如果某个依赖本身没有
go.mod（比如老式 GOPATH 包），就不会有这行 - 手动删掉
/go.mod行会导致后续go mod tidy重新补上，不影响构建，但可能拖慢首次依赖分析 - CI 环境里如果禁用了代理或校验库（
GOSUMDB=off），这行可能缺失或校验失败
checksum mismatch 错误到底该查什么
这不是网络超时或权限问题，而是内容真实不一致。错误信息里会明确给出本地计算值和 go.sum 记录值，两行哈希一模一样地列出来，差一个字符就崩。
- 先看
go.mod里有没有replace：比如replace github.com/foo/bar => ./local-patch，这时go.sum存的是你本地目录的哈希，换机器肯定不匹配 - 执行
go clean -modcache清掉缓存，再go mod download重拉——排除代理污染或中间人篡改 - 检查是否有人手动编辑过
go.sum：格式必须严格为module path version h1:xxx，空格不能多不能少，h1:后面不能有空格或换行 - 确认
GOPROXY和GOSUMDB配置一致：比如公司内网用私有 proxy，但GOSUMDB还指向sum.golang.org，就会因校验源不匹配而失败
go.sum 必须和 go.mod 一起提交吗
必须。缺 go.sum 的项目等于裸奔——新同事 clone 后 go build，可能拉到被劫持的镜像包；CI 构建机重装系统后，缓存清空，没人能保证下次下载的内容和你本地一致。
go.sum 不是“快照”，它是动态验证凭证：记录的是你当前依赖图下所有模块内容的指纹，且只在明确变更依赖时更新（如 go get、go mod tidy），不是每次构建都写。
- 别把
go.sum加进.gitignore -
go mod vendor不会修改go.sum，但vendor/目录本身不参与哈希校验——校验仍走pkg/mod缓存 - 团队协作中，每次
go.mod变更后，应连带审查go.sum新增/删除的行，确认来源可信
哈希本身不防恶意包上传，只防“同版本内容被悄悄替换”。真正安全闭环，得靠 GOSUMDB 对接透明日志服务，验证哈希是否被全球多数人共识过。这点容易被忽略，但恰恰是 go.sum 从“本地校验”升级为“分布式公证”的关键。
