go mod verify 通过比对 go.sum 中记录的 zip 包和解压后根目录的 h1 哈希值来发现模块损坏，而非依赖文件大小或时间戳；只要内容有单字节差异（如网络中断、磁盘错误、代理篡改），即报 checksum mismatch；其前提为本地已缓存依赖且 go.sum 完整，缺失条目需先执行 go mod tidy 或 go mod download 补全。
go mod verify 为什么能发现损坏的模块
它不靠文件大小或时间戳，而是直接比对每个模块 zip 包和解压后根目录的哈希值——这两条记录在 go.sum 里，分别以 h1: 开头。只要本地缓存里的文件内容哪怕改了一个字节（比如网络传输中断、磁盘写入错误、代理篡改），go mod verify 就会报 mismatch。
运行 go mod verify 的前置条件
命令本身不下载也不修复，只校验。所以必须先确保依赖已存在本地缓存：
- 项目根目录下有有效的
go.mod和go.sum - 所有依赖已下载到
$GOPATH/pkg/mod（可通过go mod download触发） - 没手动删过
go.sum或改过其中某行哈希值
如果提示 missing go.sum entry，说明该模块还没被记录校验和，不是“损坏”，而是“未初始化校验”——此时应先跑 go mod tidy 或 go mod download。
校验失败时怎么定位具体哪个包坏了
输出里会明确列出模块路径和错误类型，例如：
github.com/sirupsen/logrus v1.9.0 h1:...
some modules failed verification 后紧跟着的那几行，就是实际出问题的模块。注意区分两种失败：
-
checksum mismatch：本地文件哈希与go.sum不符 → 真实损坏或缓存污染 -
no matching hash found：go.sum里根本没这条记录 → 通常是go.mod新增了依赖但没更新go.sum
别急着重下整个缓存；先用 go list -m -f '{{.Dir}}' github.com/sirupsen/logrus@v1.9.0 查出它的本地路径，再手动 ls -l 看文件大小是否异常（比如只有几百字节），这往往是下载中断的明显信号。
清除损坏模块的最小操作范围
全局清缓存（go clean -modcache）太重，容易连带删掉其他正常模块。更精准的做法是只删出问题模块：
- 找到模块缓存路径：
$GOPATH/pkg/mod/cache/download/github.com/sirupsen/logrus/@v/v1.9.0.zip及同级.info、.mod - 删掉这三个文件（保留
.ziphash没用，它只是校验中间产物） - 再执行
go mod download github.com/sirupsen/logrus@v1.9.0 - 最后
go mod verify确认通过
真正容易被忽略的是：私有模块用了 replace 指向本地路径时，go mod verify 根本不校验它——因为 go.sum 记的是原始模块哈希，而本地路径内容变更不会触发 mismatch。这种场景下，得靠 git diff 或人工核对。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
