go 1.16+ 默认严格校验 go.mod 和 go.sum 完整性，缺失依赖声明或哈希不匹配时构建立即失败，这是安全机制而非 bug；go mod tidy 是唯一合法修改 go.mod 的命令，go.sum 不可手动编辑，gosumdb 配置错误将导致校验链中断。
go.mod 文件不完整时构建直接失败，这是默认行为
从 Go 1.16 开始，go build、go test 等命令会严格校验 go.mod 的完整性。如果它缺失直接依赖或传递依赖的版本声明，构建立即中止，而不是悄悄补全或降级——这堵住了“自动拉新包”带来的供应链缺口。
常见错误现象：CI 流水线突然失败，报错类似 missing go.sum entry 或 require statement missing。这不是 bug，是安全机制在起作用。
- 不要用
go mod download后手动删掉go.sum来“绕过校验”，这等于主动关闭防护 -
go mod tidy是唯一被允许修改go.mod的命令，但它只添加缺失项、不升级已有项，除非你显式指定版本 - 如果项目里有
replace指令，确保它指向可信路径（如内部 Git 仓库），且该路径本身受权限控制
go.sum 不只是哈希清单，它是不可绕过的验证锁
go.sum 记录每个模块版本的 SHA-256 哈希值，每次 go build 都会校验本地缓存包内容是否与 go.sum 一致。不一致就报错，不会静默替换。
容易踩的坑：
- 多人协作时误删或手动编辑
go.sum—— 它不是“可读配置文件”，而是机器生成的校验凭证 - CI 环境中执行
go get -u导致go.sum被批量更新，却没提交到代码库，下一次构建就会失败 - 使用私有代理（如 Nexus）但未配置
GOSUMDB=off或自建校验服务，会导致无法验证哈希而阻断拉取
govulncheck 是唯一官方漏洞扫描器，但必须主动触发
govulncheck 不会自动集成进 go build，它是个独立工具，需显式调用。它的数据库由 Go 团队维护，覆盖 CVE 和 Go 生态特有漏洞（比如 net/http 中的 header 注入类问题）。
实操建议：
- 在 CI 中加入
govulncheck ./...，失败时中断流水线 —— 注意它默认只报告高危及以上，可用-severity medium调整阈值 - 避免仅运行
govulncheck ./（当前目录），它可能漏掉子模块或internal/包里的调用链 - 结果里出现
indirect标记的漏洞，说明来自传递依赖，不能简单删掉，得用go mod graph | grep定位源头模块再处理
GOSUMDB 配置错误会让整个校验链失效
默认 GOSUMDB=sum.golang.org 提供全球公开校验服务，但企业内网通常需要切换。错误配置会导致 go get 卡住或跳过校验。
关键点：
- 设为
GOSUMDB=off会完全禁用校验，仅限离线开发环境，生产绝对禁止 - 设为
GOSUMDB=your-sumdb.example.com时，必须确保该服务返回标准透明日志格式，否则客户端拒绝通信 - 若使用国内代理（如
https://goproxy.cn），注意它默认不提供校验服务，需额外配GOSUMDB=sum.golang.org+insecure——+insecure表示信任该代理转发的哈希，但不验证其签名
最易被忽略的是：GOSUMDB 的响应延迟或超时不会降级为本地哈希比对，而是直接失败。网络策略必须放行其 HTTPS 请求，不能只放行 proxy.golang.org。
