go mod verify 报 missing go.sum entry 说明项目依赖缺失校验和记录，不是模块被篡改，而是 go.sum 文件不完整，常见于首次克隆后未运行模块命令或手动删除未提交 go.sum；应执行 go mod tidy 或 go mod download 补全条目，并确保 go.sum 已提交至版本控制。
go mod verify 为什么报 missing go.sum entry
说明项目依赖缺失校验和记录，不是模块被篡改，而是 go.sum 文件不完整。常见于首次克隆项目后没运行过任何模块命令，或有人手动删了 go.sum，又没提交更新后的文件。
实操建议：
- 直接运行
go mod tidy—— 它会补全所有缺失的go.sum条目，同时清理未引用的依赖 - 若只想要校验和，不改动依赖树，改用
go mod download，它会下载模块并生成对应哈希，但不会修改go.mod - 检查
go.sum是否被 Git 忽略（比如误加了go.sum到.gitignore），这会导致团队成员本地始终缺条目 - CI 环境中建议在
go mod verify前固定加一句go mod download，避免因缓存空导致 missing entry
校验失败时 go clean -modcache 不够用怎么办
go clean -modcache 清掉的是整个模块缓存，但有时问题不在缓存损坏，而在 go.sum 记录与远程实际内容不一致——比如代理返回了被污染的包，或你本地用了不兼容的 GOPROXY 配置。
实操建议：
- 先确认当前 GOPROXY：
go env GOPROXY，非https://proxy.golang.org或可信私有代理时，可能拉到中间篡改版本 - 临时禁用代理验证：执行
GOPROXY=direct go mod download，绕过代理直连源仓库（需确保能访问 github.com 等） - 若仍失败，检查对应模块的
go.sum行是否被手动编辑过（比如删了某行、改了哈希），go.sum必须由 Go 工具链自动生成 - 不要单独删
$GOPATH/pkg/mod/cache/download下某个模块子目录，容易残留不一致状态；清缓存就用go clean -modcache，重下就用go mod download
go.sum 中两个哈希值分别校验什么
go.sum 每个模块通常有两行哈希，例如：
github.com/gorilla/mux v1.8.0/go.mod h1:Rj4uZwP2Q6qy7eWYiVzX9kF3vTgZxJ+U8KfOqN5bBzA=<br>github.com/gorilla/mux v1.8.0 h1:ZvIcDdVzX9kF3vTgZxJ+U8KfOqN5bBzA=
第一行带 /go.mod 后缀的，校验该模块自身 go.mod 文件内容；第二行校验整个模块源码压缩包（.zip）的 SHA-256 值。两者缺一不可。
实操建议：
- 构建失败提示
checksum mismatch for github.com/xxx时，先看报错里带不带/go.mod—— 带则说明对方改了自己项目的go.mod（比如加了 replace），不带则是源码被改 - 某些内部私有模块用
replace指向本地路径时，go.sum不会生成对应哈希（因为没下载），此时go mod verify会跳过该校验，属正常行为 - 不要把
go.sum当作“锁版本”文件——它不控制版本选择，只做完整性校验；版本锁定靠go.mod的require和 MVS 算法
CI 中 go mod verify 应该放在哪一步
放在 go build 或 go test 之前，但不能放在 go mod download 之后立刻执行——因为 go mod download 只下载，不保证 go.sum 与当前 go.mod 同步。
实操建议：
- 标准 CI 流程应为：
go mod download→go mod tidy -v（同步go.sum并输出变更）→go mod verify - 如果项目启用了
GO111MODULE=on且go.mod在根目录，无需额外cd，否则 verify 会报 “not in module root” - GitLab CI 或 GitHub Actions 中，建议将
go mod verify的 exit code 加入 failure 判断，而非只看 stdout 是否含all modules verified—— 因为失败时它不输出成功信息，只报错退出 - 别在
go build -o bin/app .后再跑 verify：构建成功不代表依赖没被篡改，verify 必须前置
go get、go mod tidy 或甚至 go build 都可能更新它；而只要它没提交进 Git，协作时就没人知道哪些哈希该信、哪些是临时生成的。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
