go mod verify仅校验pkg/mod/cache中已下载模块的哈希值是否与go.sum一致，不联网、不验来源、不查主模块，失败主因是缓存被篡改或损坏。
go mod verify 会校验什么
它只检查 go.sum 文件里记录的模块哈希值，是否与本地 pkg/mod 缓存中对应模块的实际内容一致。不联网、不查远程、不验证模块来源是否可信，只做本地一致性比对。
常见错误现象：go mod verify 报错但 go build 正常 —— 因为构建时不会自动触发校验；或者 CI 环境里突然失败，但本地没改过依赖 —— 很可能是缓存被意外覆盖或磁盘损坏。
- 仅比对已下载到
pkg/mod/cache/download的模块，未下载的模块直接跳过 - 不校验
go.mod本身，也不检查主模块（当前项目）源码是否被改 - 校验粒度是 module-level，不是每个
.go文件单独算 hash
什么时候必须手动跑 go mod verify
主要在可信环境交接或发布前确认依赖完整性，比如：CI 流水线末尾、Docker 镜像构建完成时、向生产部署推送前。
使用场景有限，日常开发几乎不用——因为 go get 和 go build 默认不校验，除非显式开启 GOSUMDB=off 或绕过校验机制，否则篡改缓存后首次构建就会失败，根本走不到运行阶段。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启用
GOSUMDB=off后，go mod download不写go.sum，此时go mod verify会报 “no sum for module” 错误 - 用
go mod download -x可看到实际解压路径，校验就是读取那里对应的zip解压后内容再 hash - 如果模块是 replace 到本地路径的，
go mod verify完全不处理，直接忽略
go mod verify 失败的典型原因
不是网络问题，也不是权限问题，90% 是缓存文件被动了手脚。
常见错误现象：verifying github.com/some/pkg@v1.2.3: checksum mismatch，后面跟着两个 hash 值 —— 第一个是 go.sum 里的，第二个是本地算出来的。
- 手动编辑或替换过
pkg/mod/cache/download/.../list或.zip文件 - 用
rsync/cp -r拷贝整个pkg/mod目录，导致部分文件权限/时间戳异常，影响 zip 解压一致性 - 磁盘静默错误（silent corruption），尤其在 NFS 或某些云盘挂载环境下
-
go clean -modcache中断执行，留下半截损坏的模块目录
修复失败后该怎么做
别手抖删 go.sum，也别盲目 go mod tidy —— 这俩操作会重写校验和，掩盖真实问题。
先定位哪个模块坏了：go mod verify 输出里第一个报错的模块就是根因；再确认是不是真被篡改，还是只是缓存脏了。
- 运行
go clean -modcache，然后重新go mod download，最稳妥 - 只想修单个模块？删掉
pkg/mod/cache/download/github.com/some/pkg/@v/v1.2.3.zip*全套文件，再go mod download github.com/some/pkg@v1.2.3 - 如果用的是私有代理（如 Athens），检查代理是否返回了错误响应但没报错，导致缓存了坏 zip
真正难判断的是：hash 不一致，但代码逻辑没变 —— 可能是模块作者重发了同版本 tag，或你之前就关掉了 GOSUMDB 并接受了不安全的包。这种时候，go mod verify 其实是在提醒你，信任链早就断了。
