GoLand 不内置依赖漏洞扫描功能，需通过外部工具如 govulncheck 或 osv-scanner 实现；其 Inspection 仅覆盖语言级静态分析，不涉及供应链安全所需的依赖解析、漏洞库查询与可达性分析。
GoLand 本身不内置依赖漏洞扫描能力，它只能调用外部工具（如 govulncheck 或 osv-scanner）来实现检查；直接在 Settings → Inspections 里找不到“依赖漏洞”选项，不是你漏设，是它真没有。
为什么 GoLand 的 Inspection 不报依赖漏洞
GoLand 的静态检查基于 AST 和类型系统，只覆盖代码结构、未使用变量、竞态警告等语言层问题。而依赖漏洞属于供应链安全范畴，必须：
- 解析
go.mod和实际构建依赖图（go list -m all） - 联网或离线查询漏洞数据库（如
vuln.go.dev或本地osv-db） - 做可达性分析（是否真调用了有漏洞的函数），而非简单版本号比对
这些步骤超出 IDE 的职责边界。官方明确说明：GoLand 不集成 SCA（Software Composition Analysis）功能。
手动配置 govulncheck 作为 External Tool
这是目前最轻量、最贴近开发流程的方案，适合日常编码时快速验证：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 打开 Settings → Tools → External Tools，点击 + 号添加新工具
-
Name: 填
govulncheck（方便识别） -
Program: 填你本地
govulncheck的绝对路径，例如/usr/local/go/bin/govulncheck（确认已安装：运行go install golang.org/x/vuln/cmd/govulncheck@latest） -
Arguments: 填
-json .（强制 JSON 输出，便于解析；.表示当前模块根目录） -
Working directory: 填
$ProjectFileDir$（确保在含go.mod的目录下执行） - 勾选 Run console in background，避免阻塞编辑器
配置完后，右键项目根目录 → External Tools → govulncheck 即可运行。输出会显示在 Run 窗口，但注意：JSON 格式需人工阅读，或配合脚本转成可读格式。
更实用的替代：用 Terminal 集成 + 自定义快捷键
比起 External Tool，直接在 GoLand 内置 Terminal 中执行并绑定快捷键，响应更快、错误提示更完整：
- 在 Terminal 中运行：
govulncheck ./（默认人类可读格式，带漏洞描述、影响路径和建议升级版本） - 若国内网络无法访问
vuln.go.dev，先设置代理：export GOPROXY=https://proxy.golang.org,direct，再运行 - 为 Terminal 命令绑定快捷键：进入 Settings → Keymap，搜索
Terminal，右键 Send to Terminal → Add Keyboard Shortcut，设为Ctrl+Alt+V这类易触发组合 - 之后按快捷键，输入
govulncheck ./回车即可 —— 比点菜单快 3 秒以上，且错误信息（如failed to fetch vulnerability data）直接可见
这个方式绕过了 IDE 的解析限制，也避开了 JSON 解析的麻烦，是最接近“开箱即用”的真实工作流。
CI/CD 里别依赖 GoLand，用 osv-scanner 更可控
如果你真想把漏洞检查嵌入工程规范，不要指望 GoLand 同步 CI 结果。生产环境必须用 osv-scanner 并控制数据源：
- 在可联网机器上预下载离线库：
osv-scanner download-db --output ./osv-db/ - CI 脚本中指定本地路径：
osv-scanner scan --db-path ./osv-db/ --format json ./ - 关键点：
osv-scanner默认只查 Go 生态；若项目混用 Python/JS，必须额外下载对应子集并加--ecosystem go,python - GoLand 无法自动同步这类离线 DB 更新，也不能校验
SHA256SUMS签名 —— 这些必须由 CI 脚本显式完成
真正容易被忽略的是：govulncheck 和 osv-scanner 的结果不等价。前者基于调用可达性，后者基于依赖声明。一个报“未调用故无风险”，另一个可能报“版本在受影响区间”。两者得并存，不能只信其一。
