composer licenses 命令仅原样列出 composer.json 中声明的 license 字段，不校验真实性、一致性或兼容性；需配合 license-checker 等工具扫描实际代码，并人工核查分发合规性、传染性条款适用性及白名单覆盖情况。
composer licenses 命令本身不检测合规风险
它只是把每个包 composer.json 里声明的 license 字段原样列出来，不校验是否真实有效、是否与实际代码一致、是否兼容你项目用的许可证。比如一个包写 "license": "MIT"，但实际文件里没放 MIT 声明文本，或混入了 GPL 文件——composer licenses 完全不会报错。
真正要查合规，得配合 license 检查工具链
推荐组合：先用 composer licenses 快速过一遍声明值，再用专业工具扫描实际代码。常见做法：
-
composer require --dev composer/license-checker，然后跑vendor/bin/license-checker——它会读取各包的 LICENSE 文件并做内容比对 - 用
npm run license-check（如果你项目也含前端依赖）或pip-licenses（混合 Python 场景）交叉验证 - 重点盯住
proprietary、unlicensed、unknown这类模糊声明，它们大概率意味着法律盲区 - 注意
GPL-2.0-only和GPL-2.0-or-later是不同许可，后者允许升级到 GPL-3.0，前者严格锁死——composer licenses不区分，但法务会较真
为什么不能只信 composer.json 里的 license 字段？
这个字段是包作者自己填的，没有强制校验机制。常见问题包括：
- 填错：把
Apache-2.0写成Apache 2，工具可能识别失败 - 过期：包早期用 MIT，后来引入 LGPL 组件却没更新
license字段 - 嵌套依赖漏报：A 依赖 B，B 依赖 C，C 的许可证可能根本不出现在
composer licenses输出里（除非加--tree） - 私有包无声明：公司内部包常留空
license或填proprietary，但没附带内部合规审批记录
生产环境合规检查必须人工介入的环节
自动化工具能发现 80% 的明显问题，但以下三点绕不开人：
- 确认第三方包是否真的按其声明许可证分发（比如官网下载页、GitHub release assets 里的 LICENSE 文件是否齐全）
- 判断“动态链接”“SaaS 部署”等场景下，GPL/LGPL 等传染性条款是否触发——这取决于你的架构，不是命令行能算出来的
- 审查供应商提供的白名单/例外清单是否覆盖当前版本号，
composer update后旧豁免可能失效
别让 composer licenses 成为合规检查的终点，它连起点都算不上——只是帮你快速筛出哪些包值得翻源码、查官网、找法务。
