go mod verify 是 go 的依赖完整性校验命令，它比对本地缓存模块的 sha-256 哈希值与 go.sum 中记录的哈希是否一致，仅校验 zip 文件（不含 _test.go 和文档）及其 go.mod 文件的组合指纹，不下载、不安装、不修改依赖，且离线可用。
go mod verify 是什么，它校验什么
go mod verify 不下载、不安装、不修改依赖，只做一件事：比对本地已缓存模块内容的 SHA-256 哈希值与 go.sum 中记录的哈希是否一致。它校验的是模块 ZIP 文件（不含 _test.go 和文档）和其 go.mod 文件两者的组合指纹。
校验失败时输出类似这样的信息：verifying github.com/some/pkg@v1.2.3: checksum mismatch，后面紧跟着两行哈希——一行是 go.sum 里存的，一行是当前文件算出来的。这不是网络超时或权限问题，而是内容真实不一致。
- 它不验证模块来源是否可信，只确认“你上次构建用的和这次一模一样”
- 它不检查 CVE 漏洞，
govulncheck才干这事 - 它不依赖远程服务——即使离线，只要缓存还在，就能跑
为什么必须在 CI/CD 里加 go mod verify
CI 构建环境通常干净但不可控：缓存可能被复用、代理可能被污染、甚至构建机被植入恶意 patch。仅靠 go build 自动触发的校验不够保险——因为某些场景下 Go 会跳过校验（比如 GOINSECURE 开启、或 GOSUMDB=off）。
显式执行 go mod verify 能堵住这个缺口，让校验成为门禁动作。失败即中断，不给“带毒依赖”进入制品的机会。
- 建议放在
go mod download之后、go build之前 - 不要只在本地跑一次就完事；它必须是每次 PR 构建、Tag 构建的固定步骤
- 如果项目用了私有 proxy，需确保
GOSUMDB仍指向sum.golang.org或可信镜像，否则无法防御中间人攻击
go.sum 被忽略或手动编辑后的典型故障现象
最常见错误是把 go.sum 加进 .gitignore，或者为“解决冲突”直接删掉某几行。后果不是编译报错，而是静默失效——后续任何人拉代码后，go mod download 会自动生成新哈希，旧机器和新机器用的其实是不同内容的同版本模块。
另一个高频坑是 replace：若 go.mod 里写了 replace github.com/foo/bar => ./local-fix，那么 go.sum 记录的就是本地目录的哈希。换一台机器、或 CI 环境没同步该目录，go mod verify 必然失败。
- 运行
go mod verify报missing go.sum entry，说明某个依赖没校验条目，应先跑go mod tidy - 报
checksum mismatch且哈希差异明显，优先执行go clean -modcache再重拉，排除缓存污染 - 切勿手写
go.sum行：格式必须是module/path v1.2.3 h1:xxx或go:sum，少一个字符或换行符都会导致校验失败
go.sum 和 GOPROXY/GOSUMDB 如何协同防篡改
go.sum 是本地指纹库，GOSUMDB 是全球公开的指纹公证处。默认开启时，每次 go mod download 不仅写入 go.sum，还会向 sum.golang.org 查询该模块哈希是否已被其他开发者见证过。若发现不一致，Go 直接拒绝使用该模块。
这种机制能有效防御私有代理被劫持、镜像源被投毒等中间人攻击——哪怕你配置了 GOPROXY=https://my-mirror.example.com，只要 GOSUMDB 没关，Go 就会校验该镜像返回的内容是否与公共日志一致。
- 不要设
GOSUMDB=off；如需离线环境，可用GOSUMDB=sum.golang.org+insecure配合本地 checksum db -
GOPROXY设为https://proxy.golang.org,direct是安全底线：当 proxy 不可访问时 fallback 到 direct，但仍走 sumdb 校验 -
GOFLAGS="-mod=readonly"可防止意外修改go.mod或go.sum，适合 CI 环境全局启用
govulncheck ./ 扫描、人工核查关键间接依赖的维护状态，和 go mod verify 同样重要。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
