不能用 composer show --tree 生成可审计物料清单，因其仅为缩进文本、无标准格式、缺许可证/来源URL等关键字段；正确方案是组合 composer show -s --format=json 与 composer audit，并用 composer export 生成 SPDX/CycloneDX 标准 SBOM。
Composer 的 composer show --tree 无法直接生成可审计的物料清单
它输出的是带缩进的树形文本，没有标准化格式，解析困难，且默认不包含许可证、来源 URL、安全告警等审计必需字段。团队用它截图或复制粘贴到 Excel，很快就会漏版本、混包名、丢 dev-only 依赖。
真正可用的方案是组合使用 composer show -s --format=json 和 composer audit（需 Composer 2.5+），再通过脚本清洗。关键点在于：必须加 -s（--strict）参数，否则会跳过未安装的 require-dev 包；JSON 输出里 license 字段可能为 null 或数组，得兼容；source.url 不一定存在，要 fallback 到 dist.url。
用 composer export 生成 SBOM 标准格式（SPDX / CycloneDX）
Composer 2.4+ 内置了 composer export 命令，支持导出 SPDX JSON 和 CycloneDX XML/JSON。这是目前最接近“开箱即用”的合规方案，但默认只导出 production 依赖，且不包含许可证全文或 CVE 数据。
- 加
--dev才能包含 require-dev 依赖（如phpunit/phpunit） - 加
--no-dev反而会排除它们——名字有误导性，实际是“是否启用 dev 模式”，不是“是否导出 dev 包” - CycloneDX 输出里
component.type固定为library，无法区分 PHP 扩展、脚本工具或二进制依赖 - SPDX 输出不带
externalRefs，没法关联 NVD 或 GitHub Security Advisories
自动化流水线中如何稳定提取依赖元数据
CI 中执行 composer install --no-interaction --no-scripts --prefer-dist 后，不能直接读 composer.lock——它不含许可证、作者、homepage 等字段，只存 hash 和 version。可靠路径是：先运行 composer show -s --format=json > deps.json，再用轻量脚本补全字段。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
常见坑：
-
composer show依赖已安装的 vendor 目录，CI 中若用--no-install或缓存失效，会报错Package is not installed - 某些私有包在
composer show输出里source为空，但dist有 URL，需主动 fallback - PHP 8.2+ 的
json_encode()默认不转义 U+2028/U+2029，导致部分 SPDX 解析器失败，需加JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES
许可证合规检查必须绕过 composer license 的模糊匹配
composer show 返回的 license 字段常是 MIT、BSD-3-Clause 这类简写，甚至 proprietary 或空字符串。审计系统需要 SPDX ID（如 MIT → MIT，BSD-3-Clause → BSD-3-Clause），但 proprietary 实际可能是内部协议，不能直接标红。
实操建议：
- 用
spdx/license-list-data的 JSON 数据库做映射，别自己写正则 - 对
license为null或proprietary的包，强制要求在composer.json的extra.license-file字段指定路径（如./licenses/foo.txt），CI 脚本校验该文件是否存在且非空 - 发现
license字段含GPL但无明确版本号（如GPL而非GPL-2.0-only），视为高风险，需人工确认
依赖树越深，许可证传染性越难追溯。一个 dev-dependency 里的 GPL-3.0-only 包，即使没打进生产镜像，也可能违反法务政策——这点容易被忽略。
