上线前必须对Go模块全链路依赖做安全审计，重点扫描实际调用路径而非仅go.mod显式依赖，结合govulncheck、go list -m -u all、go mod graph和人工核查维护状态，并在CI中固化go mod verify等检查。
上线前对 Go 模块依赖做安全审计，不能只扫 go.mod 里显式的包——真正出问题的往往藏在二级、三级间接依赖里，比如某个被 golang.org/x/net 间接拉入的 golang.org/x/text 旧版，就可能触发 CVE-2023-45283（Unicode 处理绕过）。必须用组合命令+人工判断，且每一步都要可验证、可回溯。
用 govulncheck 扫描实际调用路径，不是“有没有依赖”
govulncheck 的价值在于它不看 go list -m all 列出的所有模块，而是分析你代码中 真实调用到的函数路径 是否命中已知漏洞。这能大幅降低误报率，尤其适合有大量未使用依赖的遗留项目。
- 运行
govulncheck ./—— 扫描整个模块，包括所有子目录和测试文件；如果只想看主模块直接依赖是否被调用，加-deps=1 - 输出里关键字段：漏洞 ID（如
CVE-2024-29155）、影响版本范围（< v0.14.0）、修复建议（upgrade to v0.14.0 or later） - 注意：它不会报“某包存在漏洞但你没调用相关函数”的情况；但如果输出为空，不代表绝对安全——数据库有延迟，且新漏洞可能尚未收录
用 go list -m -u all 和 go mod graph 定位“幽灵依赖”
很多漏洞来自没人记得自己引入过的间接依赖，比如 github.com/sirupsen/logrus 被某个日志桥接器悄悄带进来，而你项目里根本没写 import。这类包最容易被忽略，也最难清理。
- 执行
go list -m -u all，重点看末尾标[newest]或[latest]的行——这些是可用更新，但未必安全；再用go list -m -f '{{.Path}} {{.Version}} {{.Indirect}}' all | grep true筛出所有间接依赖 - 查清某个可疑包是谁拉进来的：
go mod graph | grep 'unmaintained-package' | head -5，输出形如myproject github.com/bad/dep@v0.1.0，说明它是被你的项目直接引用的；如果是good-lib github.com/bad/dep@v0.1.0，那就要去good-lib的 issue 区看是否已有修复 PR - 别信
go list -m all显示的版本号——它只反映 MVS 选中的版本；实际构建时若go.sum被篡改或replace被覆盖，运行时加载的可能是另一个版本
人工核查维护状态，重点盯三个信号
工具扫不出“作者弃坑”或“fork 自恶意分支”，这部分必须人眼确认。打开 pkg.go.dev/{module-path} 页面，快速验证三件事：
立即学习“go语言免费学习笔记（深入）”；
- “Last updated” 时间是否超过 12 个月；若模块路径含
github.com/xxx/xxx-fork或gitlab.com/yyy/zzz-mirror，点进去看 commit 频率和最近一次 merge 是否来自主仓库 - Open issues 数量是否远大于 Closed（比如 200+ open / 50 closed），且高危关键词（
panic,race,insecure）频繁出现 - Stars 数量与 GitHub 主页的
Used by数量是否严重不匹配（例如 1k stars 但Used by显示 0）——大概率是无人维护的镜像
CI 中固化检查流程，避免“这次忘了扫”
把扫描变成门禁，比靠人想起来更可靠。GitHub Actions 示例中，最易漏的是没设超时和退出码拦截：
- 在 workflow 中添加步骤：
run: govulncheck ./ || exit 1，并配timeout-minutes: 5，防止卡死 - 同时跑
go list -m -u -json all | jq -r '.[] | select(.Update != null) | "\(.Path) \(.Version) → \(.Update.Version)"'，把半年未更新的间接依赖输出为 warning（不阻断，但发 Slack 告警） - 关键：所有扫描命令必须在
go build之前执行，且共用同一个GO111MODULE=on环境；否则可能因缓存导致结果不一致
最容易被跳过的其实是 go.sum 校验环节——有人觉得“只是校验 hash”，但删掉或手动改它，会让 govulncheck 分析的依赖树和实际运行时不一致。上线前最后一道动作，永远是 go build 成功后立刻 go mod verify，失败即中止发布。
