composer licenses 命令仅输出项目自身 composer.json 中的 license 字段值，如 myapp/myproject → mit，单行且不扫描任何依赖、不读 vendor/ 或 composer.lock；真正全量检查依赖许可证的命令是 composer show --licenses。
composer licenses 命令只列出你项目根目录 composer.json 里的 "license" 字段值，一行，仅此而已。它不扫描任何依赖，也不读 vendor/ 或 composer.lock。
composer licenses 输出什么？
它输出的永远是类似这样的单行内容：
myapp/myproject → MIT
这个结果完全来自你项目自身的 composer.json 文件中 "license" 键的值。如果该字段为空、写成 "unknown" 或根本没定义，命令可能报错、静默退出，或显示空行。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 不依赖
vendor/是否存在，也不检查是否执行过composer install - 不解析任何依赖包的
composer.json，哪怕vendor/里有 100 个包，它也视而不见 -
--format=json会输出一个含name、version、license的 JSON 对象，但name和version仍是你的项目自身，不是依赖 -
--no-dev、--short、--detail等参数对输出内容无实质影响——因为根本没有“多个包”可处理
为什么很多人误以为它能扫依赖？
官方文档未明确强调其作用范围，加上命令名带 “licenses”（复数），又和 composer show 功能相邻，导致大量开发者运行后看到 myapp/myproject → MIT 就默认“全量检查完成了”。结果法务审核时发现 monolog/monolog、guzzlehttp/guzzle 等关键依赖的许可证压根没被查过。
- Composer 2.2+ 才内置该命令，低版本直接报
Command "licenses" is not defined - 即使你刚跑完
composer update，composer licenses的输出也不会多出一个字符 - 某些旧教程或博客里写的
--recursive参数，在 Composer 2.5+ 已被移除，且从未真正支持过递归扫描
真正能列出所有依赖许可证的命令是哪个？
用 composer show --licenses。这是目前 Composer 官方唯一稳定、覆盖全部已安装包的原生命令。
- 必须先执行过
composer install或composer update，否则vendor/为空，命令会失败 - 输出每行一个包，含
name、version、license字段（如MIT、["BSD-3-Clause", "GPL-2.0"]） -
--no-dev可排除require-dev中的包，适合生产环境审计 -
--format=json输出结构化数据，但注意：license字段可能是字符串、数组、null，甚至 URL，需代码健壮处理 - 它不校验 LICENSE 文件是否存在，也不验证文本内容是否匹配声明——只是忠实地读取每个包
composer.json里的"license"字段
合规审查不能只靠命令输出
composer show --licenses 给的是元数据快照，不是法律凭证。比如某个包声明 "license": "MIT"，但它的源码仓库根目录没有 LICENSE 文件，或文件内容实为 Apache-2.0，命令不会提醒你。
- license 字段支持多值（如
"MIT OR Apache-2.0"），但命令输出会合并为字符串，丢失逻辑关系 - 私有包、path 类型仓库、dev 分支引用的包，其
license字段常为空或过期，需人工补全或核查 - 真正合规需配合源码扫描工具（如 FOSSA、SCANOSS）确认 LICENSE 文件真实存在且内容一致
