composer licenses 命令不是 Composer 内置命令，官方从未实现；当前唯一原生方式是 composer show 或解析 composer.lock/json 提取 license 字段。

composer licenses 命令到底存不存在？composer licenses 在绝大多数 Composer 环境中**不是内置命令**——你执行它大概率会看到 Command "licenses" is not defined.。这不是你装错了，也不是版本太低，而是官方从未实现过这个命令。部分文档或旧插件残留描述造成了广泛误解。2026 年当前主流 Composer 2.5+ 版本中，composer show --licenses 已被移除，--licenses 参数不再支持。

• 官方唯一原生可用的许可证相关能力是 composer show（需已运行过 composer install）
• 所有带 licenses 的输出示例，基本来自第三方插件（如 zicht/composer-license-plugin）或过时资料
• 如果你在 CI 脚本里写了 composer licenses 却没装插件，构建会直接失败

怎么用原生命令查所有包的 license 字段？ 最可靠、不依赖插件的方式是解析 composer.lock 或用 composer show --format=json 提取。前提是项目已执行过 composer install（否则 vendor/ 为空，show 会报 Package not found）。

• composer show --no-dev --format=json | jq -r '.[] | "(.name),(.version),(.license // ["unknown"] | join(" | "))"'
  → 输出每行：包名,版本,许可证（支持多 license 合并显示）

• jq -r '.packages[] | "(.name)\t(.version)\t(.license // ["unknown"] | join(" | "))"' composer.lock
  → 不依赖 vendor/，但可能漏掉未在 packages 数组里显式写 license 的包（比如某些只在 packages-dev 或嵌套依赖中声明）

• license 字段值可能是字符串（"MIT"）、数组（["MIT", "Apache-2.0"]），甚至 URL（"<a href="https://www.php.cn/link/fdd62f8bdc8bd18509c0d3b5159ffc8d">https://www.php.cn/link/fdd62f8bdc8bd18509c0d3b5159ffc8d</a>"）——后者不能直接当作合规依据

• 某些包字段为空或填了 "proprietary"，需人工点进源码看根目录 LICENSE 文件

  

  Workflow Decomposer

  工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

  下载

要不要装 zicht/composer-license-plugin？ 如果你需要更贴近“开箱即用”的许可证汇总，且能接受额外依赖，zicht/composer-license-plugin 是目前最成熟的方案。装完就有 composer licenses 命令，并支持启发式识别：当 license 字段为空时，自动读取包根目录的 LICENSE 或 LICENSE.md 文件内容，尝试匹配 SPDX 标识符。

• 安装：composer require --dev zicht/composer-license-plugin
• 使用：composer licenses --format=json 或 composer licenses --short
• 它还会把 license 字段里的模糊值（如 "The MIT License"）标准化为 "MIT"，减少人工判断成本
• 缺点：插件本身不审计法律效力；仍无法替代对 LICENSE 文件原文的核对，尤其当包同时声明多个 license 或含例外条款时

为什么不能只信 license 字段？license 是 composer.json 里的元数据字段，由包作者填写，既无校验也无强制规范。常见问题包括：

• 填了 "BSD" 但实际是 BSD-2-Clause 还是 BSD-3-Clause？字段里没写清
• 有些包写 "MIT"，但 LICENSE 文件里加了额外限制（如“不得用于军事用途”），这已不是标准 MIT
• 多 license 场景下（["MIT", "GPL-3.0-or-later"]），用户必须选其一遵守，而字段本身不说明适用条件
• 更关键的是：Composer 不解析、不验证 LICENSE 文件内容，也不检查文件是否存在

真正合规审查必须落到源码仓库的 LICENSE 文件原文，再结合法务判断。工具只能帮你快速筛出 GPL、AGPL、空 license 等高风险信号，不能替你签字担责。

事情说清了就结束。