Composer 没有 licenses 命令，因其核心定位是依赖管理而非法律合规审计；它仅通过 composer show --licenses 显示未经验证的 license 字段，无法生成合规报告。
Composer 本身没有 licenses 命令，也**不提供法律合规性报告功能**。你运行 composer licenses 会得到 Command "licenses" is not defined. 错误。
为什么 composer licenses 不存在？
Composer 的核心定位是依赖安装与管理，不是许可证审计工具。它虽在 composer show --licenses 中暴露部分包的 license 字段（来自 composer.json），但该字段由包作者自行填写，未经验证，且缺失大量关键信息（如 SPDX ID、许可证文本、传染性判定、兼容性关系）。
常见误区包括：
- 误以为
composer show --licenses能生成合规报告（它只输出简短字符串，如MIT或Apache-2.0） - 忽略私有包、Git 仓库依赖、phar 包等场景下 license 字段常为空或错误
- 未考虑许可证组合带来的合规风险（例如 GPL 依赖混入 MIT 项目）
替代方案：用 composer-license-checker 生成基础许可证清单
这是目前最轻量、Composer 原生集成的许可证提取工具。它扫描 vendor/ 目录，尝试从 composer.json、LICENSE 文件、README 等位置提取信息，并输出结构化 JSON 或表格。
使用步骤：
- 全局安装：
composer global require aquasecurity/composer-license-checker - 在项目根目录运行：
composer-license-checker --format=table - 导出为 JSON 供后续分析：
composer-license-checker --format=json > licenses.json
注意点：
- 它不判断法律风险，只做“发现”；输出中的
license字段仍可能为proprietary、unlicensed或空值 - 对嵌套依赖（如 A → B → C）默认只显示直接依赖；加
--recursive才展开，但性能下降明显 - 无法识别许可证变体（如
MIT/X11和MIT是否等价需人工确认）
真正需要法律合规报告时，必须用专业工具链
开源许可证合规涉及 SPDX 标准匹配、许可证传染性分析（如 GPL-3.0-only vs GPL-3.0-or-later）、许可证冲突检测（如 MPL-2.0 与 Apache-2.0 共存是否允许）、以及人工法律审查。仅靠 Composer 生态无法闭环。
推荐组合：
- FOSSA 或 Black Duck：SaaS 方案，支持自动解析源码、识别许可证文本、标记高风险组件、生成 SOC 2/ISO 27001 就绪报告
-
ScanCode Toolkit（开源）：
scancode --license --copyright --info --strip-root --output-json-pp scancode.json vendor/，结果比composer-license-checker更底层、更准确，但需自己解析 JSON - 人工环节不可省：检查
vendor/*/LICENSE*文件原文，对照 SPDX License List 3.20+ 版本确认 ID，特别留意NOTICE文件中的额外义务
例如，若 scancode 报出某个包实际含 GPL-2.0 WITH Classpath-exception-2.0，而你项目是闭源分发，就必须替换或寻求法律意见——这一步，没有任何 Composer 命令能替你做。
小结：别被命令名误导，合规是流程不是命令
所有基于 Composer 的许可证命令都只是“起点”，不是终点。真正卡住项目的，从来不是找不到 license 字段，而是 vendor/some-private-lib 没写 license、git+ssh://... 依赖根本没进 composer.lock、或者某包虽标 MIT 但实际代码里混了 LGPL 函数——这些，只有扫描源码 + 法律审核才能覆盖。
