go mod verify 在 ci 中不可跳过，它唯一负责校验 go.sum 与实际模块内容哈希是否一致，防止依赖被篡改；vendor 模式下仍有效但仅比对 vendor/modules.txt 与 go.sum；失败主因是 go.sum 未提交或 goproxy 不一致，须前置执行并独立设为失败退出条件。
go mod verify 为什么在 CI 里不能跳过
它不是“校验模块是否下载成功”，而是验证 go.sum 文件记录的哈希值是否与当前实际下载的模块内容完全一致。CI 环境一旦跳过这步，就等于默认信任所有依赖的二进制内容——包括被中间人篡改、源站被污染、或本地缓存被意外覆盖的情况。
常见错误现象：go build 成功但运行时 panic，或不同机器构建出行为不一致的二进制；go mod download 没报错，但 go.sum 里某行被悄悄注释或删掉后 CI 仍通过。
- CI 中必须显式执行
go mod verify，不能只靠go build的隐式检查（它只在校验失败时退出，但不主动触发） - 如果用
go build -mod=readonly，它会拒绝修改go.mod或go.sum，但不会校验已有内容是否被篡改——go mod verify是唯一做这件事的命令 - 某些 CI 镜像（如
golang:1.21-alpine）默认没开 GOPROXY，可能 fallback 到直连 GitHub，此时go mod verify就更关键：网络链路越长，中间风险越高
go mod verify 在 vendor 模式下还有效吗
有效，但作用范围变了：它只校验 vendor/modules.txt 和 go.sum 是否匹配，不再检查远程模块内容。也就是说，如果你用 go mod vendor 后又手动改了 vendor/ 里的代码，go mod verify 不会发现。
使用场景：团队强制要求离线构建，或安全策略禁止 CI 访问外网。这时你得配合其他手段补位：
立即学习“go语言免费学习笔记（深入）”；
- CI 构建前先跑
go mod vendor并提交vendor/，再在构建脚本里加go mod verify—— 它会比对go.sum和vendor/modules.txt的哈希一致性 - 如果担心
vendor/被篡改，得额外加一步校验：比如用sha256sum vendor/**/* | sha256sum存档比对，或者用git status -s vendor/确保没未提交变更 -
go build -mod=vendor不会触发go mod verify，必须单独写一行命令
CI 中 go mod verify 失败的典型原因和修复路径
失败时输出类似：verifying github.com/some/pkg@v1.2.3: checksum mismatch。这不是网络问题，是本地缓存、代理或人为操作导致的哈希断裂。
常见错误现象：本地开发机执行过 go get -u，更新了某个依赖但没提交 go.sum；或者用了非官方 GOPROXY（如私有镜像），返回的内容和官方不一致。
- 优先检查
go.sum是否已提交：Git diff 里有没有漏掉新增/删减的行 - 确认 CI 使用的 GOPROXY 和本地一致，尤其避免混用
https://proxy.golang.org和私有 proxy——它们返回的 zip 包可能因压缩方式或时间戳不同导致哈希不等 - 不要用
go mod tidy -compat=1.20这类带兼容参数的命令生成go.sum，它可能引入旧版哈希规则，而 CI 用的是新 Go 版本，默认用新规则校验 - 修复方法只有两个：要么按提示运行
go mod download更新go.sum并提交；要么回退到上一个能通过go mod verify的 commit，再排查谁动了依赖
性能和并发影响：go mod verify 会拖慢 CI 吗
不会。它只读取本地磁盘上的 go.sum 和 pkg/mod/cache 中已下载的模块归档（.zip），不做网络请求，也不解压内容，纯哈希比对。实测 200+ 依赖的项目，耗时通常在 300ms 内。
但有两个边界情况要注意：
- 如果
GOENV=off或自定义了GOPATH，且pkg/mod/cache路径不可达，go mod verify会尝试重新下载——这会导致超时或失败，不是性能问题，是配置错误 - 在 CI 中用
docker run --rm -v $(pwd):/work -w /work golang:1.22 sh -c "go mod verify"时，注意挂载卷权限：若 cache 目录属主是 root，普通用户运行会跳过校验并静默失败（Go 1.21+ 已修复，但旧版本仍存在）
真正容易被忽略的是：很多人把 go mod verify 放在 go test 后面，以为“反正都构建过了”。但一旦测试失败，verify 就根本没跑——它得放在构建流程最开头，且独立设为失败退出条件。
