govulncheck 需在 go.mod 根目录运行，依赖模块图而非文件路径；“Vulnerable: true”不等于可利用，须结合 CallStack 判断调用链可达性；需联网访问 GOVULNDB，不支持离线扫描。
govulncheck 不是“一跑就准”的黑盒工具，它报的漏洞不等于可利用，不报也不代表安全——关键在理解它怎么判断、在哪会漏、哪些输出该信。
必须在 go.mod 根目录运行，否则依赖图解析失败
govulncheck 依赖 go.mod 构建模块依赖图，不是靠读文件或 vendor 目录。常见错误包括：
- 在子包目录（如
./internal/service）下直接执行govulncheck ./，结果只分析该子包 import 的部分，漏掉主模块调用链 - 在
vendor/目录下运行，报错no module found——vendor 里没有go.mod，govulncheck 根本不认 - 多模块项目用了
go.work，但没加-work参数，导致只扫当前模块，跨 workspace 的依赖不进分析范围
正确做法：cd 到含 go.mod 的根目录，运行 govulncheck ./；如果是 go.work 项目，改用 govulncheck -work ./。
CallStack 字段才是风险判断依据，别只看 “Vulnerable: true”
输出里 "Vulnerable": true 只表示该函数在漏洞数据库中有记录，不代表你的代码真调用了它。真正要盯的是 CallStack 字段：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 如果 stack 里出现你自己的包路径（如
main.go:42 → mypkg.DoSomething → vulnerable.func），说明调用链可达，需处理 - 如果 stack 全是
vendor/xxx/testutil.go或testing.*，基本是测试代码触发，生产环境不会走这条路，可忽略 - 静态分析对接口、反射、函数值调用保守，
CallStack为空或太短时，不能断定安全，得人工确认是否可能被间接调用
建议加 -json 输出后用 jq 'select(.Vulnerable == true and .CallStack != null)' 过滤出高置信度条目。
GOVULNDB 代理和 -test 参数影响结果覆盖度
默认 GOVULNDB 是 https://vuln.go.dev，国内访问常超时或返回空数据，导致“没漏洞”假象：
- 临时切代理：
export GOVULNDB=https://proxy.golang.org/vuln（注意末尾有/vuln） - 不加
-test时，*_test.go中 import 的模块不会参与分析，但有些漏洞只在测试依赖里暴露（比如 mock 库带的旧版 net/http） - 某些 indirect 依赖虽在
go.mod里，但如果没被任何.go文件 import，govulncheck 也不会检查它——这和go list -m all的行为不一致
CI 中建议固定使用 govulncheck -test -json ./，避免因本地环境差异漏掉测试路径引入的风险。
离线扫描不可行，替代方案要换工具链
govulncheck 必须联网下载漏洞数据库并实时解析模块图，它：
- 不支持纯离线模式，
-dumpdb只输出版本信息，不保存数据库文件 - 不读
vendor/内容，也不支持把go.sum当输入源 - 若项目用了
replace替换模块（如打 patch），它按替换后的 module path 查 CVE，而官方 CVE 通常只关联原始 path，必然漏报
真要离线或审计私有 fork，得换工具：用 syft 从 go.sum 生成 SBOM，再用 grype 匹配本地 NVD JSON 数据库；或者定期导出 govulncheck 结果存档，作为基线比对，而非依赖它做最终裁决。
