composer 没有 license 命令，官方从未实现；composer show 需 vendor 存在，composer.lock 更稳定但 license 字段可能为空或不规范；自动化查协议不可信，需人工核验或专业工具辅助。
composer license 命令根本不存在
你敲 composer license 或 composer licenses，得到的只会是：Command "license" is not defined.——这不是你装错了，也不是环境没配好，是 Composer 官方从没实现过这个命令。2025 年底起，连社区文档里误传的 composer show --licenses 也在 Composer 2.5+ 中被彻底移除。所有“一键查协议”的幻想，得先打住。
真正能用的只有 composer show 和 composer.lock
composer show 是唯一原生命令，但它有硬性前提：必须已执行过 composer install，且包已下载到 vendor/ 目录下；否则报 Package not found。而 composer.lock 不依赖 vendor 存在，更稳定，但字段可能为空或不全。
- 查单个包（快速验证）：
composer show monolog/monolog | grep license - 导出全部（含 dev 依赖）：
composer show --format=json --dev | jq -r '.[] | "\(.name),\(.version),\(.license // "unknown")"' - 跳过 vendor 直读锁文件（CI 友好）：
jq -r '.packages[] | "\(.name)\t\(.version)\t\(.license // ["unknown"] | join(" | "))"' composer.lock - 注意：
.license可能是字符串、数组或 null，//仅处理 null，对空数组无效，得用(array)$pkg['license']在 PHP 脚本里强转
license 字段只是元数据，不是法律保证
你看到 "license": "MIT"，不代表这个包真能闭源商用——它可能只是作者随手填的，Packagist 上未同步，甚至 LICENSE 文件实际是 GPL-3.0。更麻烦的是，有些包 license 字段写的是 "http://example.com/license" 或 "BSD-like"，SPDX 不识别，工具直接标为 unknown。
- 常见坑：
BSD-3-Clause和BSD-3-Clause-Clear法律效力不同，但composer show都只显示字符串，不区分 - 某些私有包或 GitLab 仓库未配置
repositories，show查不到 license，得手动翻源码根目录的LICENSE文件 - 插件如
zicht/composer-license-plugin能启发式扫描 LICENSE 文件内容，但依然无法替代法务人工核验
合规审计别靠 Composer 自带能力
Composer 不检查许可证兼容性，比如 MIT 包里嵌了 GPL 子依赖，它不会报警；也不校验你是否漏签声明文件。真要上生产或过 ISO 审计，得用专用工具。
- 轻量级推荐：
composer require --dev terrapiq/composer-license-check，运行./vendor/bin/license-check可设黑名单（如禁用 GPL） - 企业级方案：FOSSA、Snyk、WhiteSource，支持递归分析、LICENSE 文件哈希比对、自动生成 SPDX SBOM
- 最稳妥的脚本方案（无额外依赖）：
json_decode(file_get_contents('composer.lock'), true)后遍历$lock['packages']，对$pkg['license'] ?? ['unknown']强转数组再展开——PHP 环境里跑得最稳
真正难的从来不是“怎么查”，而是“查出来之后信不信”。license 字段空、错、旧、模糊，太常见了；自动化工具只能帮你收齐线索，没法替你签字担责。
