go mod verify只校验本地缓存而不重新下载，因其设计目标是快速验证依赖完整性而非修复或同步；它比对go.sum哈希与$gopath/pkg/mod中已存模块内容，全程离线、不触网、不修改缓存。
go mod verify 为什么只校验本地缓存，不重新下载？
因为 go mod verify 的设计目标是「快速验证完整性」，不是修复或同步。它读取 go.sum 中记录的哈希值，再比对本地 $GOPATH/pkg/mod/cache 里已解压/未解压的模块内容（zip 包 + 模块根目录），全程不触网、不改缓存。
常见错误现象：some modules failed verification 出现时，往往不是远程包被篡改，而是本地缓存损坏、go.sum 被手动编辑、或某次 go get 过程中断导致 zip 文件不完整。
- 不要用
go mod download后立刻go mod verify—— 前者可能因网络问题写入残缺 zip，后者会立刻报错 - 若 CI 流程中校验失败，优先执行
go clean -modcache再重试，而不是删go.sum -
go.sum里每个模块有两条哈希：一条是 zip 包的h1:，一条是解压后根目录的/go.mod h1:；后者能防“zip 没动但内部文件被替换”的情况
go.sum 被删或没提交，会发生什么？
后果很直接：go build 或 go test 会失败，报错 checksum mismatch 或 missing go.sum entry。Go 工具链在构建时强制校验，不是可选项。
这不是 bug，是安全机制。没有 go.sum，就等于放弃对依赖完整性的断言。
- 首次拉代码后，必须运行一次
go mod download或go build自动生成go.sum，再提交到 Git - 团队协作中，有人删了
go.sum又没重新生成就提交，其他人git pull后第一次构建必炸 -
go mod tidy会更新go.sum，但不会删除已有条目；手动删条目等同于主动绕过校验，绝对禁止
私有模块为何容易校验失败？
因为默认走 proxy.golang.org + sum.golang.org 校验链，而私有仓库（如 GitLab 内网地址）既不在代理白名单，也不向官方 sumdb 提交哈希。结果就是：Go 工具链找不到对应哈希，或 fallback 到本地计算哈希但发现跟 go.sum 不符。
根本原因不是“私有模块不安全”，而是校验路径断裂。
- 必须设置
GOPRIVATE=git.example.com（替换成你的真实域名），让 Go 跳过代理和 sumdb 校验 - 此时
go.sum仍会记录哈希，但只基于你本地 clone 的内容生成，后续所有机器都得从同一可信源拉代码 - 如果用了自建 proxy（如 Athens），需确保其配置了
sumDB同步策略，否则go mod verify在不同环境结果不一致
go mod verify -tag 是干什么的？
这是 Go 1.25 新增的实验性功能（当前稳定版尚未包含），专为模块发布者设计：它允许你在打 tag 后、推送到远端前，本地验证「这个 tag 指向的 commit，是否真能生成跟未来 sumdb 记录一致的哈希」。
换句话说，它堵住了“本地打 v1.2.3 → 推送后被强制覆盖 → 全世界拉到的其实是另一份代码”这个信任缺口。
- 用法很简单：
go mod verify -tag v1.2.3，前提是当前目录是模块根，且本地 git 有该 tag - 它会模拟 Go Proxy 的打包逻辑（zip + go.mod 提取 + 哈希计算），输出是否匹配 sumdb 预期
- 注意：这不是日常开发命令，CI 发布流水线才需要；普通用户保持
go mod verify就够了
go.sum 初始生成时源头就有问题（比如从被攻破的镜像站拉包），那后续所有 go mod verify 都只会确认这个坏哈希。所以首次 go mod download 的来源可信度，比反复校验更重要。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
