go.sum校验的是模块zip解压后.go文件及go.mod文件的两阶段dirhash哈希，不是简单sha256、不校验版本号、不锁定间接依赖路径，更非锁文件；它通过本地比对+远程sum.golang.org背书防篡改。
go.sum 校验的是什么，不是什么
它校验的是模块 ZIP 包解压后所有 .go 文件（不含测试、文档）内容的 SHA256 哈希，以及该模块自身 go.mod 文件的哈希——两者都经过 Go 定义的两阶段 dirhash 算法生成，不是简单对文件做 shasum -a 256。它不校验版本号、不参与版本选择、不锁定间接依赖的“路径”，更不是 package-lock.json 那类锁文件。
常见错误现象：verifying github.com/sirupsen/logrus@v1.9.3: checksum mismatch 报错时，很多人第一反应是“版本写错了”，其实问题大概率出在：上游重打了 v1.9.3 tag、你本地缓存损坏、或 GOPROXY 返回了被篡改的内容。
-
h1:xxx行对应模块源码压缩包内容（不含go.mod） -
github.com/sirupsen/logrus v1.9.3/go.mod h1:yyy行对应其go.mod文件本身哈希 - 哈希值隐式绑定路径名，防止攻击者把 A 模块的
go.mod复制到 B 模块目录冒充
go.sum 被自动更新的几种真实场景
它只在真正触发模块内容下载或重新计算时才变，不是每次 go build 都动它。关键触发点有：
- 首次执行
go mod download或go build，所有依赖第一次拉取并写入哈希 -
go get github.com/gorilla/mux@3f5e24b6—— 显式指定 commit hash，Go 解析成v0.0.0-20230101000000-3f5e24b6abcd并写入新行 - 删掉
$GOPATH/pkg/mod/cache后重建，即使版本没变，也可能因 Go 工具链升级导致归档方式微调，从而生成新哈希 -
go mod tidy -v会清理未被go.mod中require直接或间接引用的整行（但保留/go.mod行）
注意：go mod vendor 不修改 go.sum；replace 到本地路径后，go.sum 记录的是你本地文件内容的哈希，换机器就失效。
checksum mismatch 时该怎么安全处理
别删 go.sum、别加 -mod=mod、更别手动改哈希。先确认变更是否可信：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 运行
go list -m -json github.com/some/pkg@v1.2.3查 Go 解析出的实际 commit 和 source URL - 手动访问该 URL 对应 zip（如
https://github.com/some/pkg/archive/v1.2.3.zip），用shasum -a 256算哈希，再和go.sum里h1:后的 base64 编码比对（需转成 hex 才能对照） - 若哈希确实变了且你信任发布源，运行
go mod download github.com/some/pkg@v1.2.3让 Go 重写条目 - 若不确定，用
go mod graph | grep some/pkg查谁引入了它，再决定降级或联系上游
最常被忽略的一点：go.sum 里某模块出现多行，未必是错误——可能是项目里同时存在 v1.2.0 和 v1.5.0 两个版本的间接依赖，Go 允许共存，各自校验。
为什么必须提交 go.sum 到 Git，且不能跳过校验
不提交 go.sum，等于放弃构建一致性底线。CI/CD 构建机、新同事、甚至你重装系统后第一次 go build，都可能拉到被污染的依赖（比如恶意代理返回带后门的包），而你毫无察觉。
校验失败时 Go 会同时做两件事：本地比对 + 远程查询 sum.golang.org。哪怕你本地 go.sum 被改错，只要远程数据库没这条记录，Go 就会拦截并警告——这是供应链攻击的第一道防线。
容易被忽略的细节：GOSUMDB=sum.golang.org 默认开启，但如果你设了 GOSUMDB=off 或指向不可信的私有 sumdb，那这层保护就失效了；GOFLAGS="-mod=readonly" 能防止意外改 go.mod 和 go.sum，建议加进 CI 环境变量。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
