必须手动运行govulncheck ./...而非依赖goland内置扫描，因其默认仅扫当前文件且缺关键参数；需结合-format=json、-offline及go list -json -deps定位幽灵依赖并优先修复matched=true的cve漏洞。
直接用 govulncheck，别依赖 IDE 内置按钮
GoLand 2026.1.1 虽然集成了“Run Security Scan”菜单项，但它只是包装了 govulncheck 命令，且默认不带关键参数。直接点菜单容易漏检——它默认只扫描当前文件，而不是整个模块。真正有效的做法是手动运行命令，并确保工作目录在项目根（即有 go.mod 的地方）：
-
govulncheck ./...：扫描所有子包（推荐，覆盖完整依赖调用链） -
govulncheck -format=json ./...：输出结构化结果，方便后续解析或集成到 CI - 避免只跑
govulncheck .：它只检查当前目录，深层依赖里的漏洞可能被跳过
govulncheck 报告里哪些漏洞该优先处理
报告里一堆 CVE 不代表都要立刻升级。Go Vuln DB 的核心价值在于「是否被实际调用」——它会结合 AST 分析，判断你代码中是否真调用了存在漏洞的函数路径。重点关注以下三类条目：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
osvID字段以CVE-开头，且matched为true：说明你的调用栈确实经过了漏洞函数 -
module是你直接依赖（出现在go.mod中），而非 transitive 依赖：修复成本低，升级即可 -
package和function和你业务逻辑强相关（比如net/http.(*ServeMux).ServeHTTP）：这类比golang.org/x/crypto/.../pbkdf2更值得优先响应
CI/CD 中集成时必须加 -offline 和缓存
在 GitHub Actions 或 GitLab CI 里直接跑 govulncheck 容易失败，原因不是网络超时，而是首次运行时要下载漏洞数据库（约 15MB）。不控制的话，每次构建都重下，拖慢流水线还可能触发限流。
- 加
-offline参数：强制使用本地缓存副本，但前提是先预热缓存 - 在 CI job 开头执行：
govulncheck -download（仅首次或数据库更新时需运行） - 把
~/.cache/go-vuln目录设为缓存路径（GitHub Actions 用actions/cache，GitLab 用cache:） - 别在
go build阶段顺手跑扫描：它不阻塞编译，但错误退出码（如发现高危漏洞）应明确设为fail-fast
和 go list -json -deps 结合能定位「幽灵依赖」
有时 govulncheck 报出某个间接依赖的漏洞，但 go.mod 里根本没它——这是 Go Module 的 replace 或 indirect 依赖导致的「幽灵模块」。光靠 go mod graph 看不清调用路径。
- 运行：
go list -json -deps -f '{{if .Module}}{{.Module.Path}} {{.Module.Version}}{{end}}' ./... | sort -u - 对比输出和
govulncheck报告里的module，快速识别哪些是被某第三方库悄悄带进来的 - 若想临时压制误报（不推荐长期用）：
govulncheck -exclude=github.com/some/bad/pkg@v1.2.3
go test -cover）才是帮你做决策的关键工具——得确认改了之后，那块逻辑还能被测到。
