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 文件
要不要装 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 文件内容，也不检查文件是否存在
composer show（需已运行过 composer install）licenses 的输出示例，基本来自第三方插件（如 zicht/composer-license-plugin）或过时资料composer licenses 却没装插件，构建会直接失败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文件
要不要装 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 文件内容，也不检查文件是否存在
composer require --dev zicht/composer-license-plugin composer licenses --format=json 或 composer licenses --short license 字段里的模糊值（如 "The MIT License"）标准化为 "MIT"，减少人工判断成本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 等高风险信号，不能替你签字担责。
事情说清了就结束。