go mod verify是验证Go项目依赖完整性的权威命令，仅比对本地缓存模块与go.sum中记录的SHA-256哈希值，输出“all modules verified”表示内容未被篡改或损坏，否则明确提示失败模块及哈希差异，是CI/CD中保障依赖安全的必要门禁步骤。
直接运行 go mod verify，输出 all modules verified 才算健康；只要有一处校验失败，就说明依赖内容已被篡改、缓存损坏或 go.sum 与实际模块不一致——这不是“可能有问题”，而是明确不可信。
用 go mod verify 看校验结果是否可信
这个命令不下载、不修改任何文件，只比对本地已缓存模块内容和 go.sum 中记录的 SHA-256 哈希值。它是最轻量、最权威的“健康快照”判断方式。
- 输出
all modules verified：说明所有模块内容完整，未被代理劫持、镜像污染或本地误改 - 输出
some modules failed verification：错误行会明确写出模块路径和两个哈希值（downloaded:h1:xxxvsgo.sum:h1:yyy），这就是第一手证据 - 注意：它不检查模块是否过时、是否有 CVE，只管“内容是否和上次一样”——这是安全的底线，不是全部
为什么 go mod download 后必须跟 go mod verify
CI/CD 或新机器拉代码后，仅执行 go mod download 只保证模块“能下下来”，但无法防御中间人篡改或私有代理返回脏包。必须紧接着跑一次 go mod verify 来确认指纹没变。
-
go mod download本身不会触发校验，它只是填充$GOPATH/pkg/mod/cache -
go build会自动校验，但你不能等构建失败才发现问题——尤其在 CI 中，应把go mod verify作为独立门禁步骤 - 若校验失败，优先执行
go clean -modcache清空缓存，再重试go mod download && go mod verify，避免残留污染
校验失败时，别急着删 go.sum 行
看到 checksum mismatch 就手动删 go.sum 里对应行，再 go mod tidy 重写——这是最常见也最危险的操作。你绕过了完整性保护，等于主动接受未知内容。
- 先确认是否用了
replace：检查go.mod是否有类似replace github.com/some/pkg => ./local-fix，这种情况下go.sum记的是本地路径哈希，换环境必然失败 - 检查是否从非官方源拉取：比如设置了
GOPROXY=https://goproxy.cn，但该镜像同步滞后或被污染，可临时切回https://proxy.golang.org重试 - 真实哈希不一致，90% 是上游包被恶意覆盖（如作者账号被盗）或你本地缓存被植入 patch，此时应暂停上线，人工核查该模块近期 commit 和 pkg.go.dev 页面更新时间
真正容易被忽略的点是：校验通过 ≠ 依赖健康。一个模块可能指纹完全正确，但它早已停止维护、存在未公开的逻辑漏洞、或其间接依赖链里藏着一个 github.com/xxx/codec 的恶意 fork。所以 go mod verify 是必要条件，不是充分条件——它只保底，不兜底。
