go mod verify 用于校验本地模块与go.sum中哈希值是否一致，失败表明存在篡改、代理污染或上游重发tag等风险；成功则输出“all modules verified”，是比go build更早发现坏包的安全防线。
坏包通常不是“下载失败”，而是下载成功但内容被篡改、版本错乱或校验失效——go mod verify 会直接报错，go build 可能静默引入风险代码。核心判断依据是 go.sum 校验失败或模块哈希不匹配远程日志。
用 go mod verify 立即验证本地模块完整性
它比 go build 更早暴露问题：不依赖编译逻辑，只比对本地 go.sum 和权威校验源（如 sum.golang.org）的哈希值。
- 运行
go mod verify，若输出all modules verified，说明当前缓存中所有模块 checksum 匹配；若报checksum mismatch或missing hash，就是坏包信号 - 必须确保
GOSUMDB=sum.golang.org已启用（go env GOSUMDB应返回该值），否则校验只走本地go.sum，无法发现首次拉取时就被污染的情况 - 如果
go mod verify失败但go build成功，说明你本地go.sum被手动修改过、或用了GOSUMDB=off，此时整个模块缓存不可信，应立即执行go clean -modcache并重试
定位具体哪个模块坏了：结合 go list -m -json 和 go.sum 手动比对
go list -m -json all 输出每个模块的 Path、Version 和 Dir，而 go.sum 里每行对应一个 module@version 的哈希。二者不一致，就说明该模块被替换了。
- 从
go mod verify报错中提取出出问题的模块名和版本，例如golang.org/x/net@v0.14.0 - 运行
go list -m -json golang.org/x/net@v0.14.0，检查其Dir字段是否指向$GOPATH/pkg/mod/cache/download/...下的真实路径 - 打开
go.sum，搜索该行，确认哈希是否与sum.golang.org上查到的一致（可访问https://sum.golang.org/lookup/golang.org/x/net@v0.14.0） - 若
Dir指向的是replace后的本地路径（如./vendor/x/net），则go.sum不会包含其哈希——这不是坏包，而是你主动绕过了校验，需人工审查该目录内容
排查代理或私有源导致的“假坏包”
国内用户常因 GOPROXY 配置不当，从非官方镜像拉到不一致或延迟同步的版本，表现为 go mod verify 失败，但换源后正常。
- 临时切回直连模式验证：
GOPROXY=direct go mod download golang.org/x/net@v0.14.0，再跑go mod verify—— 若通过，说明原代理源有问题 - 检查
GOPRIVATE是否漏配：若模块来自公司内网 Git，但未加入GOPRIVATE，Go 仍会尝试走代理，可能返回 403 后 fallback 到错误版本，或静默跳过校验 - 私有 proxy（如 JFrog Artifactory）若未开启
sum.golang.org透传或缓存校验逻辑，也会导致go.sum写入错误哈希——此时需联系 infra 团队确认 proxy 的 Go Modules 支持级别
真正难排查的是 replace 后的本地模块：它不进 go.sum，go mod verify 完全不检查，但它的代码改动会直接影响构建产物。这类“坏包”只能靠 git status 或 diff 对比原始 commit，没有自动化捷径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
