必须在ci中运行go mod verify，因为它校验本地模块哈希与go.sum是否一致，防止被污染代理或中间人篡改；不运行即默认信任缓存，失败时应中断构建而非依赖go build的静默警告。
go mod verify 为什么必须在 CI 里跑
不跑 go mod verify，就等于默认信任本地缓存的模块没被篡改过——而缓存可能来自被污染的代理、中间人劫持，甚至开发机被植入恶意软件。它不下载新包，只比对 go.sum 里的哈希和本地模块文件实际内容，失败时直接报错中断。
- CI 第一步就该执行
go mod verify；失败则拒绝构建，别等go build完了才发现问题 - 本地开发也建议每次拉完新分支后手动跑一次，尤其当你用过
GOPROXY=direct或私有代理 - 如果输出
missing go.sum entry，说明某个模块没被记录校验和，不是删go.sum，而是先跑go mod download再重试 - 别依赖
go build自动触发校验——它只在校验失败时警告，不中断，容易被忽略
govulncheck 怎么扫全依赖，不是只扫 main
govulncheck ./ 默认只分析你项目代码里直接调用的路径，大量漏洞藏在测试代码或间接依赖里，比如某个日志库引入的 golang.org/x/net 里的 HTTP 解析逻辑，./ 根本不会覆盖到。
- 必须加
-test参数：运行govulncheck -test ./扫描测试代码链路，很多高危包（如golang.org/x/crypto）只在 test 中出现 - 别指望 “no vulnerabilities found” 就安全——可能是调用路径没进分析范围，或漏洞还没被收录进 vuln.go.dev 数据库
- 扫描结果里的
GO-XXXX-XXX是 Go 官方编号，不是 CVE，别拿它去搜 NVD - 若用 GitHub Actions，记得在
actions/setup-go后显式安装最新版：go install golang.org/x/vuln/cmd/govulncheck@latest
go.sum 文件哪些操作会踩坑
go.sum 不是“校验通过就万事大吉”的静态快照，它是动态校验链的一环，错误操作会让整个机制失效。
- 绝不能把
go.sum加进.gitignore——团队成员拉代码后无法校验一致性，等于裸奔 - 不要手动编辑
go.sum条目，尤其是删掉某行再go mod tidy；这会跳过远程 checksum database（sum.golang.org）比对，失去防中间人能力 - 遇到
checksum mismatch错误，先确认是否用了不可信 proxy；再尝试go clean -modcache+go mod download，而不是直接删go.sum -
go.sum只保证“和上次一样”，不保证“第一次引入的就是干净的”——所以得配合govulncheck和人工核查维护状态
间接依赖怎么盯住不漏掉
真正出事的往往不是你 require 的那个库，而是它下游七拐八绕带进来的 github.com/xxx/yyy@v0.0.1，没人认得、没人维护、但天天在解析 XML 或解密 JWT。
- 用
go list -m all | grep -E "(golang\.org/x|github\.com/.*\.(sql|http|crypto|xml))"快速筛高频风险包 - 查谁引入它：
go mod graph | grep "golang.org/x/text"，再结合go mod why golang.org/x/text看调用链 - 对
// indirect包，访问pkg.go.dev页面看 “Last updated” 和 open issues 数量；超过 6 个月没 commit 的，优先考虑替换 - CI 里可解析
go list -m -u -json all输出，自动告警更新滞后超 180 天的间接依赖
go.sum 当成和 go.mod 一样严肃的合约文件，以及是否接受“间接依赖不需要我 require，就不归我管”这种错觉。
