go mod verify只校验本地缓存模块内容哈希与go.sum记录是否一致，不下载、不更新、不联网查远程源；校验两类哈希：zip包原始内容（h1:）和解压后树哈希，二者缺一不可。
go mod verify 校验什么、不校验什么
它只比对本地已缓存模块（$GOPATH/pkg/mod）的内容哈希与 go.sum 中记录的哈希是否一致，不下载、不更新、不联网查远程源——哪怕某个模块根本没下载，go mod verify 也会跳过它，不会报错“missing”。真正触发下载的是 go mod download 或 go build。
校验对象包括两类哈希：
-
h1:前缀的哈希：对应模块 zip 包原始内容（即从 proxy 下载的归档文件） - 无前缀（或
h12:等）的哈希：对应解压后模块根目录的树哈希（tree hash），防篡改解压过程或手动修改源码
这两者都必须匹配，才算通过。只改源码不改 zip，或只换 zip 不解压，都会导致其中一项失败。
为什么 go.sum 被修改后 verify 必然失败
go.sum 不是锁文件，但它是校验锚点——它的每一行格式固定为：<module> <version> <hash>，且同一模块不同版本会独立成行。Go 工具链在生成时严格按路径+版本+内容计算，任何空格、换行、大小写改动都会让哈希不匹配。
立即学习“go语言免费学习笔记（深入）”；
常见误操作包括：
- 用编辑器保存时自动删尾随空格或转 DOS 换行（
\r\n） - 手动添加/删除某行，却没运行
go mod tidy同步间接依赖条目 - 在 CI 中用了不同 Go 版本（如 1.21 vs 1.23），其哈希算法微调导致生成的
go.sum行不兼容
此时 go mod verify 会明确输出类似 github.com/sirupsen/logrus v1.9.0: checksum mismatch，并指出期望哈希和实际哈希。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go mod verify 在 CI 中必须配合 GOSUMDB 和 go mod download
默认情况下，go mod verify 只比对本地缓存和 go.sum，但它无法发现你第一次下载时就下到了被污染的模块——比如私有 proxy 返回了中间人篡改包，而你的 go.sum 记录的就是那个坏包的哈希。
要堵住这个缺口，必须设置：
-
GOSUMDB=sum.golang.org：强制让 Go 工具链在校验时也查询官方 sumdb 日志，比对三方共识哈希 - 前置执行
go mod download：确保所有依赖已拉取到本地缓存，避免verify因缓存缺失而跳过模块
CI 脚本中推荐顺序：go mod tidy -v && go mod download && go mod verify。漏掉 download，verify 可能静默跳过未缓存模块；不设 GOSUMDB，等于只信自己第一次下的那个“坏种子”。
go mod verify -tag 是作者侧的新校验维度
当前稳定版（Go 1.24）的 go mod verify 只校验“下游用了什么”，而即将落地的 -tag 标志（预计 Go 1.25）首次把校验视角转向“上游发了什么”。它允许模块作者在打 tag 后立即运行：
go mod verify -tag=v1.2.3
该命令会：
- 读取本地 git 仓库中
v1.2.3标签指向的 commit - 检出该 commit，构建模块 zip 并计算其哈希
- 比对这个哈希是否与 sum.golang.org 上已收录的
v1.2.3记录一致
这解决了发布环节的关键盲区：你本地 git tag v1.2.3 推上去的代码，是否真就是全世界通过 go get 拿到的那个版本？没有 -tag，你只能等几小时甚至几天，看 proxy 和 sumdb 是否同步成功，再靠下游反馈——而那时漏洞或篡改可能已扩散。
