composer licenses 命令仅显示当前项目 license 字段，不列任何依赖包许可证；真正可行的是 composer show –all（需 vendor 已安装）或解析 composer.lock（ci 友好），但二者字段来源不同、结果可能不一致。
composer licenses 命令根本不管用
它只显示你当前项目的 license 字段（比如 myapp/myproject → MIT），**一个依赖包的许可证都不会列出来**。很多人一试就以为“全量扫描成功”，结果法务审核时才发现漏了 90% 的依赖。
- 它不读
composer.lock，不查vendor/，也不管require-dev - 输出里只有顶层项目那一行，和“查看所有包许可证”完全无关
- 官方文档没写清楚这点，导致大量误用
真正能批量查 license 的只有两个可靠路径
要么靠 composer show（需 vendor 已安装），要么直读 composer.lock（CI 友好、无需 install）。两者字段来源不同，结果可能不一致——这是常态，不是 bug。
-
composer show --format=json --all：列出所有已安装包（含 dev），.license来自包的composer.json元数据，但若没运行过composer install就报错 -
jq -r '.packages[] | "(.name)t(.version)t(.license // ["unknown"] | join(" | "))"' composer.lock：跳过 vendor，直接解析锁文件；但有些包在 lock 里license字段为空或为 URL（如"https://example.com/LICENSE"），此时 jq 会输出unknown - 二者 license 字段都只是作者填的字符串，
"MIT"不等于法律有效，"BSD-like"更是等于没写
license 字段不是法律依据，只是线索
你看到 "license": ["MIT", "GPL-3.0"]，不代表你可以随意选；看到 "license": "proprietary"，也不代表它真受保护——很多私有包根本没 LICENSE 文件。
- SPDX 标识符（如
MIT、apache-2.0）才具备工具识别基础，"BSD-3-Clause-Clear"和"BSD-3-Clause"法律效力不同，但 composer 一律当字符串处理 - 必须去源码仓库根目录找
LICENSE或LICENSE.md，用正则匹配全文（比如搜gnu GENERAL public LICENSE.*Version 3），否则过不了 ISO 合规审计 - 某些 gitlab 私有包未配置
repositories，composer show查不到，composer.lock里又没写 license，只能手动翻代码
轻量合规检查推荐用 terrapiq/composer-license-check
它比原生命令多走一步：不仅读 license 字段，还尝试下载 LICENSE 文件做内容校验，并支持黑名单机制，适合 CI 阶段卡点。
- 安装：
composer require --dev terrapiq/composer-license-check - 运行：
./vendor/bin/license-check，默认输出所有包 + license + 是否在黑名单中 - 配置禁止 GPL：
"forbidden": ["GPL-2.0", "GPL-3.0"]写进license-check.json即可 - 但它依然不解决“嵌套依赖带传染性协议”的问题（比如 MIT 包里含 GPL 子模块），这种得上
php-library-compliance或人工审计
实际工作中，最常被忽略的是：license 字段为空 ≠ 没有许可证，而是作者懒得填；license 字段有值 ≠ 可商用，得看 LICENSE 文件原文和使用方式。别让一行 "license": "MIT" 成为你上线前的最后一道幻觉。