go mod verify 为什么突然报 checksum mismatch
go mod verify 报 checksum mismatch，不是模块被篡改了，大概率是你本地缓存的校验和（go.sum）和当前模块实际内容对不上——可能因为：模块作者重写了 tag、重新发布同版本二进制、或你之前用过 -mod=readonly 跳过写入却手动改过 go.sum。
常见错误现象：
• go build 正常，但 go mod verify 失败
• go get 后没动代码，go mod verify 却报错
• 同一 commit，不同机器结果不一致
- 先确认是否真被篡改：运行
go list -m -json all | grep -E 'Path|Version|Sum'查看当前解析出的Sum值，和go.sum里对应行比对 - 如果只是本地
go.sum过时，执行go mod download -json再go mod tidy，它会自动刷新校验和（前提是模块未被撤回） - 别直接删
go.sum—— 这会让后续go mod verify失去基准；应删掉对应模块行，再让go mod tidy重生成 - 注意
replace指令会绕过校验：若用了replace example.com/m => ./local/m，go mod verify不检查本地路径内容，只校验原始模块记录
go.sum 文件里每行 checksum 的生成逻辑
go.sum 不是哈希源码，而是哈希「归档包解压后所有文件的路径+内容」拼接后的 SHA256 —— 也就是 zip/tar.gz 解开后，按字典序遍历每个文件，把 路径\n长度\n内容 串起来再算哈希。所以哪怕只是模块里一个测试文件多空了一行，校验和就全变。
使用场景：
• CI 环境做构建前完整性断言
• 审计时比对公开仓库与本地依赖实际内容是否一致
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 模块没有
go.sum行？说明它被声明为indirect且未被直接依赖，或你用go mod init初始化时没触发完整图计算 -
go.sum里同一模块可能有两行：一行带/v2后缀（语义化版本），一行不带（legacy）；这是 Go 兼容旧模块的妥协，不是错误 - 私有模块（如
git.example.com/internal/lib）的 checksum 也照常生成，但前提是GO_PRIVATE配置正确，否则go mod download都拉不下来，更不会写入go.sum
go mod verify 在 vendor 模式下的行为差异
启用 vendor 后，go mod verify 默认仍读取 go.sum 校验远程模块，**不校验 vendor/ 目录里的文件内容** —— 它只确保你 vendor/ 里的代码和当初 go mod vendor 时下载的归档包一致，而不是“现在从网络拉下来的包”是否一致。
性能影响：
• go mod verify 本身很快（只读 go.sum 和本地缓存），但加 -v 会逐个解压比对，慢 10 倍以上
• vendor 模式下，go mod verify 不访问网络，适合离线审计
- 想校验
vendor/实际内容？得自己用go mod vendor -v+ 手动比对go.sum记录的哈希，Go 工具链不提供该能力 -
go mod vendor会把所有go.sum里的模块都复制进vendor/，包括indirect依赖；但go mod verify仍只按go.sum记录校验，不管vendor/是否完整 - CI 中建议：先
go mod download，再go mod verify，最后go mod vendor—— 这样能确保 vendor 前已通过校验，避免把问题带进目录
哪些情况 go mod verify 实际上不生效
go mod verify 是静态校验，不运行代码、不分析 AST、不查漏洞，它只回答一个问题：“我本地缓存的模块内容，和当初记录的校验和是否一致”。所以它对以下情况完全无感：
- 模块作者在不改版本号的前提下，悄悄更新了
main.go并重推 tag（Git 允许 force push tag）—— 只要归档包哈希变了，go.sum就失效，但go mod verify会立刻报错，这反而是它的价值 - 你用
go get example.com/m@v1.2.3拉的是 commit hash，但go.sum记的是该 commit 对应的 pseudo-version（如v1.2.3-0.20220101000000-abcdef123456），此时go mod verify校验的是 pseudo-version 对应的归档，不是 tag 名 - 模块含 Cgo 或需要构建时动态链接的代码，
go mod verify不验证构建产物，只验源码归档 - 如果你关掉了
GOSUMDB（设为空或off），go mod verify仍工作，但它失去对公共模块的第三方签名验证（比如 sum.golang.org 的透明日志），仅依赖本地go.sum
最常被忽略的一点：校验和只绑定到模块路径+版本组合，不绑定 Go 版本、平台或构建标签。同一个 go.sum 行，在 macOS 和 Linux 下 go mod verify 结果一致，但编译行为可能完全不同。
