composer licenses 命令仅在 composer 2.2+ 原生支持，低版本会报错；需用 composer --version 确认，升级执行 composer self-update；输出含 name、version、license（字符串或数组）、license-file 字段；license 值仅为元数据，须人工核对真实 license 文件；json 格式用 --format=json，顶层为数组，多许可证保留原数组结构；--no-dev 可排除 dev 依赖；license: unknown 表示 composer.json 未声明 license，需手动核查源码仓库。
composer licenses 不是所有 Composer 版本都支持的命令——它只在 Composer 2.2+ 中原生内置；低于这个版本会报错 Command "licenses" is not defined。你运行失败，大概率不是配置或插件问题，而是版本卡在了 2.1 或更早。
怎么确认自己能不能直接用 composer licenses
先看版本：
composer --version
输出形如 Composer version 2.2.22 或更高，才能放心用；若显示 2.1.14 或更低，该命令就不存在。
- 升级方式：运行
composer self-update（需有写权限） - CI 环境中要注意：Docker 镜像、GitHub Actions 的
php-actions/composer等可能默认带旧版，得显式指定composer-version: '2.5'类参数 - 别试
composer require zicht/composer-license-plugin来“补”这个命令——那是老方案，新版原生命令已覆盖其核心功能，混用反而导致冲突
composer licenses 的输出到底包含哪些字段？
默认执行 composer licenses 会列出所有已安装包（含 require-dev），每组信息包括：
-
name：包名（如monolog/monolog） -
version：实际安装版本（来自vendor/，不是composer.json声明的约束） -
license：取自各包composer.json中的license字段值，可能是字符串（"MIT"）或数组（["MIT", "Apache-2.0"]） -
license-file：是否在包根目录下找到LICENSE或LICENSE.md文件（仅作提示，不校验内容）
注意：license 字段值不等于法律意义上的许可证全文——它只是元数据声明，必须人工核对对应包的源码仓库中真实 LICENSE 文件内容，尤其是遇到 proprietary、unlicensed、unknown 或空值时。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
导出 JSON 用于自动化检查的正确姿势
用 --format=json 是最稳妥的机器可读方式，但要注意三点：
- 输出是合法 JSON，但顶层是数组（不是对象），直接
cat licenses.json | jq '.[0].name'可取第一个包名 - 多许可证如
["MIT", "BSD-2-Clause"]会被完整保留为数组，不要用.license | join(" OR ")硬转——SPDX 规范要求逻辑连接符必须是OR/AND/WITH，而数组本身才是原始事实 - 想过滤掉 dev-only 依赖？加
--no-dev：composer licenses --no-dev --format=json > prod-licenses.json
别用 composer show --format=json 替代——它只返回顶层依赖，漏掉所有传递依赖（比如 symfony/console 依赖的 psr/log 就不会出现）。
为什么有时看到 license: unknown？
这表示该包的 composer.json 根本没写 license 字段，或者字段值为空/非法（如 null、{}）。常见于：
- 内部私有包（未声明，或声明为
"proprietary"） - 老旧包（2015 年前发布，规范意识弱）
- 某些 fork 分支（维护者删掉了原 license 声明）
此时不能跳过——必须手动进 vendor/{vendor}/{package}/ 目录，打开 LICENSE 文件或查 GitHub 仓库的 main 分支根目录。很多“unknown”实际是 MIT，但也可能是无明确授权的代码，法律风险在此类包上最高。
