Trivy 编程语言生态扫描覆盖指南：SBOM、漏洞与许可证检测的语言支持全景

本文基于 Trivy 官方文档 docs/guide/coverage/language/index.md 及其目录下的语言专项文档（Ruby、Python、PHP、Node.js、.NET、Java、Go、Rust、C/C++、Elixir、Dart、Swift、Julia），系统梳理 Trivy 对各编程语言及其依赖文件的支持范围，帮助你回答"我的技术栈能否被扫描、该扫描哪个目标、会读取哪些文件、各语言能力有何差异"这类问题。读完本文，你将能对照项目实际形态（代码仓库/文件系统/容器镜像/rootfs）确定扫描文件名、理解 SBOM / 漏洞 / 许可证 三类检测的能力边界，并掌握文件路径无关性与 --file-patterns 定制等关键行为。

一、三种通用能力与两种目标形态

1.1 编程语言扫描提供的三类能力

Triviv 对编程语言的扫描统一围绕三种能力展开：

• SBOM（软件物料清单）：把锁文件或安装元数据中的依赖解析成结构化清单，用于生成 CycloneDX / SPDX 等格式的 SBOM，参见 docs/guide/supply-chain/sbom.md；
• Vulnerabilities（漏洞检测）：将解析出的依赖与漏洞数据库比对，参见 docs/guide/scanner/vulnerability.md；
• Licenses（许可证检测）：识别每个依赖的许可证类型，参见 docs/guide/scanner/license.md。

值得注意：不是每种语言、每个文件都同时支持以上三项。例如 Bundler（Ruby）的 Gemfile.lock 支持 SBOM 与漏洞但不支持许可证，而 RubyGems 的 .gemspec 三项全支持；Conda（Python）只支持 SBOM 与漏洞，不支持许可证。本指南后面的"能力矩阵"章节会逐项给出对照。

1.2 Pre-build 与 Post-build：决定"读什么文件"的第一原则

Trivy 文档明确说明：具体扫描哪些文件取决于扫描目标（target），而目标在依赖信息层面被归为两大类：

• Pre-build（构建前）项目：例如代码仓库（Repository）或普通文件系统（Filesystem）。此时项目尚未被打包，Trivy 读取的是构建过程中生成的锁文件 / 清单文件，如 Gemfile.lock、package-lock.json、Cargo.lock 等。
• Post-build（构建后）工件：例如容器镜像（Image）或 rootfs 文件系统。依赖已经被安装/打包，Trivy 读取的是已安装包的元数据，例如 .gemspec、egg-info/PKG-INFO、二进制文件内部嵌入的依赖信息等。

举例来说，同一个 Java 项目：

• 以仓库/文件系统为目标扫描时，Trivy 解析 pom.xml、*gradle.lockfile、*.sbt.lock；
• 以容器镜像为目标扫描时，Trivy 解析镜像里的 *.jar / *.war / *.par / *.ear 归档。

从源码结构看，这两类解析逻辑被组织在 pkg/fanal/analyzer/language 下：ruby/、python/、php/、nodejs/、java/、golang/、rust/、c/、dart/、elixir/、swift/、julia/ 等目录对应各语言的具体分析器，而某个分析器究竟在哪种 target 下被启用，则由上层 pkg/fanal/analyzer 的组装逻辑决定。

一个重要的细节是：被分析文件的路径无关紧要。Trivy 不关心锁文件位于目录树的哪个层级，只要扫描范围内存在该文件即可命中。原文以 Dockerfile 示例（即 trivy-ci-test 测试仓库）佐证"文件名匹配优先于路径匹配"这一设计。

二、语言覆盖总表（四种扫描目标的文件粒度矩阵）

原文档用一张核心矩阵给出了 Trivy 支持的 14 种语言/生态、对应的被分析文件，以及在 Image（镜像）、Rootfs、Filesystem（文件系统）、Repository（Git 仓库） 四种目标下是否启用。下表完整复刻该矩阵：

语言	被分析文件	Image	Rootfs	Filesystem	Repository
Ruby	Gemfile.lock	-	-	✅	✅
	gemspec	✅	✅	-	-
Python	Pipfile.lock	-	-	✅	✅
	poetry.lock	-	-	✅	✅
	uv.lock	-	-	✅	✅
	requirements.txt	-	-	✅	✅
	egg 包（*.egg-info、*.egg-info/PKG-INFO、*.egg、EGG-INFO/PKG-INFO）	✅	✅	-	-
	wheel 包（.dist-info/METADATA）	✅	✅	-	-
PHP	composer.lock	-	-	✅	✅
	installed.json	✅	✅	-	-
Node.js	package-lock.json	-	-	✅	✅
	yarn.lock	-	-	✅	✅
	pnpm-lock.yaml	-	-	✅	✅
	bun.lock	-	-	✅	✅
	package.json（node_modules 下的已安装包）	✅	✅	-	-
.NET	packages.lock.json	✅	✅	✅	✅
	packages.config	✅	✅	✅	✅
	.deps.json	✅	✅	✅	✅
	*Packages.props（支持 Directory.Packages.props 与旧式 Packages.props）	✅	✅	✅	✅
Java	JAR/WAR/PAR/EAR（*.jar、*.war、*.par、*.ear）	✅	✅	-	-
	pom.xml	-	-	✅	✅
	*gradle.lockfile	-	-	✅	✅
	*.sbt.lock	-	-	✅	✅
Go	Go 构建的二进制	✅	✅	-	-
	go.mod / go.sum	-	-	✅	✅
Rust	Cargo.lock	✅	✅	✅	✅
	用 cargo-auditable 构建的二进制	✅	✅	-	-
C/C++	conan.lock	-	-	✅	✅
Elixir	mix.lock	-	-	✅	✅
Dart	pubspec.lock	-	-	✅	✅
Swift	Podfile.lock	-	-	✅	✅
	Package.resolved	-	-	✅	✅
Julia	Manifest.toml	✅	✅	✅	✅

其中：✅ 表示启用，- 表示关闭。逐项释读这张表可以提炼出三条规律：

1. 锁文件类（Pre-build）几乎只出现在 Filesystem / Repository 两列：Gemfile.lock、Pipfile.lock、composer.lock、package-lock.json、pom.xml、go.mod 等都只适合在尚未打包的源码目标中解析；
2. 安装元数据 / 归档类（Post-build）几乎只出现在 Image / Rootfs 两列：.gemspec、egg-info、installed.json、package.json（node_modules 下的包）、JAR 归档、Go 二进制、cargo-auditable 二进制只在"依赖已被安装或打包"的场景才有意义；
3. 少数文件"通吃"四种目标：.NET 的 packages.lock.json、packages.config、.deps.json、*Packages.props，以及 Rust 的 Cargo.lock、Julia 的 Manifest.toml 在 Image、Rootfs、Filesystem、Repository 全部启用。这通常意味着对应分析器会依据实际内容同时兼容"已安装环境"与"源码树"两种形态（如 Julia 的 Manifest.toml 既会存在于镜像环境也会出现在仓库中）。

2.1 文件名相关的脚注细节

• egg 包实际匹配四类文件：*.egg-info、*.egg-info/PKG-INFO、*.egg 与 EGG-INFO/PKG-INFO；
• wheel 包实际匹配 .dist-info/METADATA；
• JAR 族实际匹配 *.jar、*.war、*.par、*.ear；
• mix.lock 与 conan.lock 是默认文件名，若要扫描自定义文件名，需要使用 --file-patterns（file-patterns）机制，相关用法见 docs/guide/configuration/skipping.md 的 Customizing File Handling 一节；
• .NET 的 *Packages.props 同时支持集中式包管理引入的 Directory.Packages.props 和旧式 Packages.props。

2.2 关于 --file-patterns 的补充

文档指出 mix.lock、conan.lock 属于"默认文件名"，扫描自定义文件名需要配合 --file-patterns。其通用语法是把"分析器类型:文件模式"作为参数传给 trivy fs / trivy repo 等命令，例如针对 pip 的 requirements-*.txt 可写作：

trivy fs --file-patterns "pip:requirements-.*\.txt" .

需要特别强调两点行为约束（出自 docs/guide/configuration/skipping.md 第 68～104 行）：

• --file-patterns 不会关闭 Trivy 的默认文件检测行为，它只是"额外新增"基于指定模式的检测；
• 模式类型与待分析语言绑定（如 pip:、dockerfile:），且可多次传入以叠加多个模式。

三、语言专项深入：从矩阵到每门语言的细粒度能力

总表之外，Trivy 对每门语言还提供"扫描器支持"、"特性总览（传递依赖 / 开发依赖 / 依赖图 / 位置）"两张细分表。以下按生态聚合给出关键结论与文件路径，细节可点击各语言文档原文深入。

3.1 Ruby（Bundler + RubyGems）

参考 docs/guide/coverage/language/ruby.md：

包管理器	文件	传递依赖	依赖图	位置
Bundler	Gemfile.lock	✅	✅	✅
RubyGems	.gemspec	-	-	-

• Bundler 支持 SBOM、漏洞与依赖图；许可证能力为 -（不支持）。
• RubyGems 的 .gemspec 不含传递依赖，需要对每个 .gemspec 文件分别扫描。

3.2 Python（pip / Pipenv / Poetry / uv / pylock + Egg/Wheel/Conda 打包）

参考 docs/guide/coverage/language/python.md。Python 生态解析的清单文件包括 Pipfile.lock、poetry.lock、uv.lock、requirements.txt 以及 PEP 751 定义的 pylock.toml（也支持 pylock.<identifier>.toml 变体）。

包管理器	文件	传递依赖	依赖图	开发依赖处理
pip	requirements.txt	-	-	随报告包含
Pipenv	Pipfile.lock	✅	-	随报告包含
Poetry	poetry.lock	✅	✅	默认排除，--include-dev-deps 开启
uv	uv.lock	✅	✅	默认排除，--include-dev-deps 开启
pylock	pylock.toml	✅	✅	默认排除，--include-dev-deps 开启

值得展开的实战要点：

• requirements.txt 只含直接依赖：由于该文件通常只声明直接依赖，Trivy 默认只扫描直接依赖。若想覆盖传递依赖，文档推荐两种"锁定化"手段——pip freeze（在已安装的虚拟环境中执行）或 pip-compile（仅解析不安装）。

• pip 版本说明符解析策略：默认只解析带 == 且不带 .* 的版本说明符；开启 --detection-priority comprehensive 后，Trivy 会为难以确定精确版本的情况建立最小版本，此时会解析 >=、~= 与带尾部 .* 的说明符。示例如下：

  keyring >= 4.1.1            # 最小版本 4.1.1
  Mopidy-Dirble ~= 1.1        # 最小版本 1.1
  python-gitlab==2.0.*        # 最小版本 2.0.0
  

  对不支持的说明符，文档给出了两种迁移路径：用 pip-compile（不安装包）或将 pip freeze 输出回写 requirements.txt：

  $ cat requirements.txt
  boto3~=1.24.60
  click>=8.0
  json-fix==0.5.*
  $ pip install -r requirements.txt
  ...
  $ pip freeze > requirements.txt
  

• 许可证检测的"降级来源"：requirements.txt 本身不含许可证信息，Trivy 改为读取 site-packages 下的 METADATA 文件；它会依次通过 VIRTUAL_ENV 环境变量、python/python3/python2/python.exe 二进制相对路径 ../lib/pythonX.Y/site-packages 与 ../../lib/site-packages 三种方式定位 site-packages。Pipenv、Poetry、uv、pylock 均不支持许可证检测。

• Poetry 依赖图的前提：要构建正确的依赖图，pyproject.toml 必须与 poetry.lock 相邻存在；pylock 场景同理，需要 pyproject.toml 来确定直接依赖与 dev 标记。

• 打包格式（镜像/rootfs 场景）：Egg 匹配 *.egg-info、*.egg-info/METADATA、*.egg-info/PKG-INFO、*.egg、EGG-INFO/PKG-INFO；Wheel 匹配 .dist-info/METADATA。

3.3 Node.js（npm / Yarn / pnpm / Bun）

参考 docs/guide/coverage/language/nodejs.md：

包管理器	文件	传递依赖	依赖图	位置
npm	package-lock.json	✅	✅	✅
Yarn	yarn.lock	✅	✅	✅
pnpm	pnpm-lock.yaml	✅	✅	-
Bun	bun.lock	✅	✅	✅

四种包管理器均支持 SBOM、漏洞与许可证。要点：

• 开发依赖：npm 默认不报告开发依赖（--include-dev-deps 可开启）；pnpm 的 lockfile v9 开始支持 Dev 字段，同样是 --include-dev-deps 控制；bun.lock 内含包组信息，同样默认排除 dev 依赖。
• 许可证来源：npm 从 v2 起的锁文件直接取许可证；信息缺失时再分析锁文件旁 node_modules。Yarn 分析 .yarn（Yarn 2+）或 node_modules（Yarn Classic）。pnpm 与 Bun 则要求事先 install 出 node_modules。若 package.json 的 license 字段引用外部文件（如 SEE LICENSE IN LICENSE、LicenseRef-LICENSE），Trivy 会读取该文件进行许可证归类。
• Yarn 的关系补全：yarn.lock 本身不包含"直接/间接依赖"关系，也不含生产/开发分组，Trivy 通过锁文件旁的 package.json 与 workspace package.json 补全这些信息（并用于支持 Yarn aliases）。
• Bun 的版本差异：Bun v1.2 默认生成文本格式 bun.lock，v1.1.39 可用 bun install --save-text-lockfile 生成；旧版可用 bun install -y 生成 Yarn 兼容的 yarn.lock 交给 Trivy。注意 bun.lockb（二进制）不支持。
• 镜像内的已安装包：镜像扫描依赖 node_modules 下的 package.json，且只取包名、版本与许可证，不分析其 dependencies 字段。文档特别提醒：要在容器镜像中检测 Node.js 依赖漏洞，必须让镜像包含 node_modules，或改用带锁文件的文件系统扫描。

3.4 .NET（.NET Core / NuGet）

参考 docs/guide/coverage/language/dotnet.md：

包管理器	文件	传递依赖	依赖图
.NET Core	*.deps.json	✅	✅
NuGet	packages.config	✅	-
NuGet	*Packages.props	-	-
NuGet	packages.lock.json	✅	✅

• *.deps.json 只把运行时依赖纳入报告（dev 依赖被排除）。
• packages.config 只解析包名与版本；要建依赖图请用 packages.lock.json（需先在项目中启用 NuGet lock 文件，详见文档链接）。
• 许可证：packages.config 无许可证信息，Trivy 读取全局包缓存目录中的 *.nuspec 判定；目前仅支持默认路径与 NUGET_PACKAGES 环境变量。注意不解析已废弃的 licenseUrl，只读取 license 字段（仅 expression 类型）。

3.5 Java（JAR/WAR/PAR/EAR / pom.xml / Gradle lock / SBT lock）

参考 docs/guide/coverage/language/java.md。Java 是四种文件形态并存、且"构建前/构建后"区分最典型的语言：

• 归档文件（镜像/rootfs）：Trivy 解析 JAR 内的 pom.properties 与 MANIFEST.MF 主段落获取 ArtifactID / GroupID / Version。信息不足时会尝试在 trivy-java-db 中检索（实验性功能，Java DB 命中任意 JAR 时自动下载/更新，存放于缓存目录）。外层 JAR 中内嵌的 JAR 会用同一套逻辑递归处理；table 输出格式只显示根 JAR 名，要看内嵌 JAR 全路径需用 json 格式。
• 归档许可证的四个来源（按序尝试）：① 内嵌 POM 的 <licenses> 块（按 groupId:artifactId 匹配）；② Jenkins 插件清单的 Plugin-License-Name 属性（含 -2 等后缀变体）；③ OSGi Bundle-License 清单头；④ JAR 根或 META-INF/ 下的 LICENSE / LICENCE / COPYRIGHT 文件（内容走许可证分类器）。其中 URL 会对照 SPDX license list 的 seeAlso 映射为 SPDX ID，映射失败则跳到下一来源；uber/shaded JAR 因归属不明会跳过许可证文件。文档同时指出覆盖率有限：许多 JAR 只在父 POM 声明许可证，或干脆没有 Maven 描述符。
• pom.xml（仓库/文件系统）：Trivy 会按 Maven 语义依次在项目目录、relativePath 字段指向位置、本地仓库目录（Linux/macOS 为 ~/.m2/repository，Windows 为 C:/Users/<username>/.m2/repository）查找依赖，再回退到 POM 中声明的远程仓库与 Maven Central，并复刻 Maven 的仓库选择优先级（snapshot 只查 snapshot 仓库，release 先查 POM 仓库再查 Central）。连接 Maven 远程仓库可用 --offline-scan 关闭（注意它不影响漏洞数据库下载；离线时找不到的依赖可能被跳过）。

  • 镜像（mirrors）：既支持 settings.xml 的 <mirrors>（全局与用户级），也支持 Trivy 配置文件中的 scan.maven.mirrors 列表，并支持两条来源链式解析（settings.xml 把 repo1→repo2、config 把 repo2→repo3 时，repo1 最终解析到 repo3）。配置示例：

    scan:
      maven:
        mirrors:
          - source: https://repo.maven.apache.org/maven2/
            targets:
              - https://my-internal-mirror/maven2/
              - https://backup-mirror/maven2/
    

    若想镜像 Maven Central，source 用 https://repo.maven.apache.org/maven2/。警告：config 中的镜像不读 settings.xml 的凭据，明文嵌入 URL 不安全，生产环境建议走 settings.xml。

  • 支持的作用域：仅扫描 import、compile、runtime 与空作用域，其余作用域与 Optional 依赖暂不分析；父 POM 不可达或硬版本约束含多版本时，依赖版本记为空，且空版本依赖的子依赖不被检测。

  • maven-invoker-plugin：**/[src|target]/it/*/pom.xml 这类集成测试目录被当作开发依赖默认跳过，可用 --include-dev-deps 展示。

• Gradle lock：*gradle.lockfile 只含被使用的依赖，全本地解析、无需联网；默认排除 dev 依赖。实验性的依赖树功能会从缓存目录（$GRADLE_USER_HOME/caches / $HOME/.gradle/caches）的 *.pom 里找子依赖，由于无法可靠判定直接依赖，Trivy 把所有依赖标记为间接后用启发式重建依赖树；许可证同样依赖这些缓存 POM。
• SBT lock：build.sbt.lock 由 sbt-dependency-lock 插件生成，全本地解析、无需联网，只含被使用的依赖。

3.6 Go（go.mod/go.sum 与 Go 二进制）

参考 docs/guide/coverage/language/golang.md。Go 的检测贯穿"构建前（模块）"与"构建后（二进制）"两个维度：

版本	所需文件	离线
>=1.17	go.mod	✅
<1.17	go.mod, go.sum	✅

• Go 1.17+ 用 go.mod 获取直接/间接依赖（go.mod 已收纳编译所需的间接依赖，误报更少）；Go ≤1.16 则 go.mod 管直接依赖、go.sum 管间接依赖——而 go.sum 会包含大量"不需要编译"的间接项。注意"Go 版本"指 go.mod 里的 go 指令而非本机工具链版本，升级可用 go mod tidy -go=1.18。
• 主模块不被检测：Trivy 只扫描项目的依赖。例如扫描 Docker 源码/二进制时可能命中 Docker 所依赖的 Go 模块漏洞，但不会报告 Docker 自身。
• 标准库（stdlib）检测：go.mod 中 go 与 toolchain 指令可辅助推测 Go 版本，但因不确定性强，仅在 --detection-priority comprehensive 下启用，取二者最小值，且刻意不读取本机 Go 工具链以保证结果可复现；stdlib 检测仅对 Go 1.21+ 生效，且可能产生误报。缓解方式：用 govulncheck 分析可达性，或用忽略文件/VEX 压制不适用项。
• 许可证与依赖图：需要先 go mod download / go mod tidy / go mod vendor 把模块拉进本地缓存；若存在 vendor/ 目录则优先用它，否则遍历 $GOPATH/pkg/mod。
• Go 二进制：Trivy 在扫描镜像/文件系统时遇到 Go 二进制会解析其构建期嵌入的依赖与 Go 版本信息。主模块版本方面：go install 安装的二进制含正确 semver；其它情况常为 (devel)，此时 Trivy 依次尝试解析 -ldflags、ELF 符号表，仍失败则版本为空（本地 replace 的依赖也会空版本）。文档明确提示 UPX 压缩的二进制无法工作。

3.7 Rust（Cargo 与 cargo-auditable 二进制）

参考 docs/guide/coverage/language/rust.md。Cargo 与二进制都支持 SBOM 与漏洞，许可证均不支持。Cargo.lock 在四种目标下全部启用：

• Cargo.lock 不含"直接依赖"信息，为准确显示依赖树，需在其旁放置 Cargo.toml；两者一起扫描还能剔除开发依赖。
• 用 cargo-auditable 构建的二进制会内嵌依赖清单，Trivy 识别并扫描这类二进制。

3.8 C/C++（Conan）

参考 docs/guide/coverage/language/c.md。Conan v1/v2 的 conan.lock 支持 SBOM、漏洞与许可证：

• lockfile v1 支持依赖树，v2 的间接依赖会被纳入分析但不会在依赖树中显式标注；
• 许可证来源特殊：锁文件本身不含许可证，Trivy 解析 Conan 缓存目录中的 conanfile.py（v1 缓存目录与 v2 CONAN_HOME 缓存目录）来获得许可证——因此要求本地缓存包含全部所用依赖；
• conan.lock 是默认名，自定义文件名需用 --file-patterns。

3.9 Elixir（Hex / mix.lock）

参考 docs/guide/coverage/language/elixir.md。Trivy 通过 mix.lock 解析 Hex 依赖，支持 SBOM 与漏洞（许可证不支持），不支持依赖图但支持位置定位。mix.lock 为默认文件名，自定义名需 --file-patterns。

3.10 Dart（pubspec.lock）

参考 docs/guide/coverage/language/dart.md。pubspec.lock 支持 SBOM、漏洞（许可证不支持），开发依赖被随报告包含（因为该文件无法区分 root 与 dev 的传递依赖）。

• SDK 依赖：Dart 对 SDK 依赖（如 Flutter）记版本 0.0.0，无法精确确定；开启 --detection-priority comprehensive 后 Trivy 会用约束的最小版本（例中 flutter 约束 ^3.3.0 则取 3.3.0）。
• 依赖树：Trivy 解析 pub 缓存目录（默认目录或 PUB_CACHE 环境变量，仅绝对路径）；构建依赖树前建议 dart pub get 补全缓存。

3.11 Swift（SwiftPM 与 CocoaPods）

参考 docs/guide/coverage/language/swift.md。SwiftPM 的 Package.resolved 支持 SBOM 与漏洞；CocoaPods 的 Podfile.lock 支持 SBOM、漏洞与依赖图：

• 扫描前记得用 swift package update 刷新 Package.resolved；
• CocoaPods 的一个已知局限：Trivy 依赖的 GitHub Advisory Database（GHSA）使用 Git URL 而非 CocoaPods 包名，Trivy 通过解析 CocoaPods Specs 建立映射；由于 GHSA 只持有仓库级 URL，Trivy 无法区分同一仓库下的不同子模块，例如 SwiftNIOHTTP1 与 SwiftNIOWebSocket 同属 github.com/apple/swift-nio，CVE-2022-3215 会被同时报告给两者，尽管实际只影响其一。

3.12 Julia（Pkg.jl / Manifest.toml）

参考 docs/guide/coverage/language/julia.md。Manifest.toml 支持 SBOM、漏洞与依赖树（许可证不支持），四种目标全部启用：

• 依赖树需在 Manifest.toml 旁放置 Project.toml，两者一起扫描还可剔除开发依赖；依赖扩展（extension）当前被忽略。

四、从文档到实现：分析器在仓库中的落点

上述能力并非空谈，它们对应到仓库的明确源码位置，便于读者按需溯源：

• 各语言的依赖解析器集中位于 pkg/fanal/analyzer/language，其下 ruby/、python/（含 conda/ 子目录）、php/、nodejs/、dotnet/、java/、golang/、rust/、c/、dart/、elixir/、swift/、julia/ 与本文矩阵中的语言一一对应，每目录内既包含解析器源码也包含对应锁文件的测试数据（如 nodejs/ 下的 *.json/*.yaml lockfile 样例、golang/ 下的 *.mod/*.sum 等），是研究各文件解析细节的第一手材料。
• 语言包（library）漏洞的检出/比对逻辑位于 pkg/detector/library，detect.go 负责把解析出的包与漏洞数据匹配；OS 包漏洞则走 pkg/detector/ospkg（该路径面向操作系统软件包，不在本文语言矩阵内，但同属漏洞检出流水线）。
• 针对各语言"目标×文件"的实际启停，integration 端到端测试（integration/integration_test.go 与 integration/testdata 下大量 *-scan.json.golden、*.json.golden 黄金文件，例如 cargo.lock.json.golden、gomod.json.golden、pom.json.golden、yarn.json.golden、pubspec.lock.json.golden 等）提供了可对照的期望输出，验证了"某语言某文件在特定目标下产出何种扫描结果"。

五、快速自查清单：选对目标、备好文件

结合以上全部内容，实际使用时可按下述思路自查：

1. 确定目标形态：若是代码仓库/目录，走 Filesystem 或 Repository 扫描，此时应确保把锁文件提交进仓库（文档在多个语言章节反复提醒"修改依赖后请保持锁文件最新"，如 Node.js 与 .NET 章节）；若是镜像/rootfs，走 Image / Rootfs 扫描，需保证镜像内已安装包的元数据存在（Node.js 要求 node_modules、Python 要求 site-packages、Ruby 要求 .gemspec）。
2. 核对语言能力：查第 2 节总表确认"文件 × 目标"启用关系；查对应语言小节确认 SBOM/漏洞/许可证三项与传递依赖、依赖图、开发依赖策略。多数语言默认排除 dev 依赖，统一用 --include-dev-deps 纳入。
3. 关注前置条件：Go 模块许可证/依赖图需先拉取本地模块缓存；Dart 依赖树需 dart pub get；Composer 依赖树需 composer.json 与 composer.lock 同目录；Poetry/pylock 依赖图需 pyproject.toml 相邻；Julia 依赖树需 Project.toml 相邻；pnpm/Bun 许可证检测需先生成 node_modules。
4. 按需定制与降噪：默认文件名不匹配时用 --file-patterns（只增不替）；对 pip 等无法锁定精确版本的场景考虑 --detection-priority comprehensive；Java pom.xml 依赖 Maven 仓库时可用 --offline-scan；Go 标准库、Swift 子模块等已知误报场景参考各语言章节的 Caveats 处理。

语言覆盖是动态演进的（本仓库对应版本的文档即含 .NET 的 *Packages.props、Python 的 pylock.toml、Node.js 的 Bun 等较新条目），本指南以 docs/guide/coverage/language/index.md 为骨架、以 docs/guide/coverage/language 下各语言专项页为细节来源，如需最深度的字段级说明，建议直接跟随文中各语言文档的源码与测试路径继续阅读。