composer licenses 命令仅原样输出依赖包 composer.json 中的 license 字段，不校验真实性或合规性；需配合 license-checker、CI 硬检查及人工核对 GPL 等高风险协议才能实现法律合规闭环。
composer licenses 命令本身不判断风险，只照搬依赖包 composer.json 里写的 license 字段——写错、漏写、瞎写它都照显示，别把它当法律审查员。
怎么用 composer licenses 快速看全量协议
在项目根目录直接运行：composer licenses。它会列出所有已安装的包名、版本、作者和声明的许可证（如 MIT、Apache-2.0、GPL-3.0-only）。
- 想导出为机器可读格式？加
--format=json：命令变成composer licenses --format=json，适合后续用jq过滤或集成进 CI - 嫌信息太杂？加
--short只留包名和协议：composer licenses --short输出形如monolog/monolog MIT - 只关心生产环境？加
--no-dev排除开发依赖：composer licenses --no-dev
为什么看到 “MIT” 也不能放心？常见误判场景
很多开发者扫一眼全是 MIT 就以为高枕无忧，但实际漏洞常藏在细节里：
-
license字段是纯字符串，Composer 不校验真实性——一个包写了"license": "MIT"，但源码里压根没放 MIT 许可证文本，或混入了 GPL 文件，composer licenses完全不报错 - 多许可证写法必须用 SPDX 标准逻辑符：
"MIT OR Apache-2.0"✅，而["MIT", "Apache-2.0"]❌（旧版 Composer 会截断成空或第一个） -
unlicensed、proprietary、unknown这类值不会触发警告，但往往意味着法律盲区，法务看到会立刻叫停上线
真正要控风险，得补上这三步验证
composer licenses 是起点，不是终点。合规闭环至少要补三环：
- 用
composer require --dev composer/license-checker装工具，再跑vendor/bin/license-checker——它会真去读每个包的LICENSE文件内容，比对是否匹配声明 - CI 中加一行硬检查：比如只允许
MIT/Apache-2.0/BSD-3-Clause，其他一律失败：composer show --no-dev --format=json | jq -r '.[].license // ["UNLICENSED"] | .[]' | grep -qE '^(MIT|Apache-2.0|BSD-3-Clause)$' || (echo "non-compliant license found"; exit 1) - 对含
GPL或AGPL的包特别敏感：GPL-2.0-only和GPL-2.0-or-later法律效力完全不同，composer licenses不区分，但你得手动核对
最易被忽略的一点：你改了自己项目的 composer.json 里的 license 字段，只是更新 Packagist 页面上的徽章，既不控制代码权限，也不影响 composer install 行为——它就是个标签，不是开关。真要卡流程，得靠 composer audit 或自定义脚本拦截。
