composer 2.2+才原生支持composer licenses命令；此前版本需用composer show --licenses --recursive --format=json（2.1.12+）导出完整依赖许可证，注意license字段可能为空、为数组或非spdx标准格式，须人工核验github license文件。
Composer 没有原生 composer licenses 命令——除非你用的是 Composer 2.2+，否则直接运行会报错 Command "licenses" is not defined。 这不是你装错了，也不是权限问题，而是官方在 2.2 版本才正式加入该命令。低于此版本（比如大量仍在用的 2.1.x 或更早），它根本不存在。
怎么确认自己能不能用 composer licenses
先查版本：
composer --version
输出类似 Composer version 2.2.22 才算达标；若显示 2.1.14 或更低，别试了，命令无效。此时你看到的所有“教程示例”都是白搭，强行运行只会失败。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 2.2+：支持
composer licenses、--format=json、--no-dev、--locked等参数 - 2.1 及以下：只能靠
composer show --licenses --recursive --format=json（需 2.1.12+）或手动解析composer.lock - 旧版连
--recursive都不认，composer show --licenses只返回顶层依赖，漏掉 90% 的许可证信息
composer show --licenses --recursive --format=json 是最稳的兜底方案
这条命令不依赖插件、不挑版本（2.1.12 起可用），且能真正展开整个依赖树，比 composer licenses 更早覆盖合规审计需求。输出是标准 JSON，字段清晰：name、version、license。
-
--recursive是关键：没有它，只扫composer.json里写的包，子依赖全被忽略 -
license字段为空或"unknown"很常见——这不代表没许可，只是composer.json没填或填得不规范（如写成"BSD"而非"BSD-3-Clause"） - 遇到
"unknown"，必须人工查对应包的 GitHub 仓库根目录下的LICENSE文件，Packagist 页面上显示的“License”不可信
导出和过滤许可证时最容易踩的坑
很多人导出后直接拿 Excel 统计，结果把 ["MIT", "Apache-2.0"] 当成一个许可证，或把 GPL-2.0-only 和 GPL-2.0-or-later 混为一谈——法务会较真，这两者法律效力完全不同。
-
composer show输出的license字段可能是字符串，也可能是数组；脚本处理时务必用is_array()或jq '.[] | .license'展开，不能直接echo $pkg['license'] - SPDX 标准要求多许可证用
OR/AND连接，如"MIT OR Apache-2.0"✅，而["MIT", "Apache-2.0"]❌（旧版 Composer 会截断） - 用
jq过滤 GPL 类时，别只写grep -i gpl：有些包写"gpl-3.0"，有些写"GPL-3.0-only"，大小写+连字符+后缀都得覆盖
真正麻烦的从来不是命令跑不跑得通，而是 license: unknown 后那一堆要逐个点进 GitHub 查 LICENSE 文件的包——自动化只能帮你列出来，不能替你读法律条文。
