composer licenses 命令导出的是各已安装包的 name、version 和 license 字段值（取自 composer.json），不校验真实性，不可用于法律合规审计，仅作快速参考。
composer licenses 命令导出的是什么
composer licenses 不生成标准 SPDX 或 SBOM 格式清单，也不包含许可证全文，它只输出每个已安装包的 name、version 和 license 字段值（取自 composer.json 中的 license 键）。这个字段由包作者填写，可能为空、写错（比如填成 MIT 但实际没附 LICENSE 文件），甚至填成模糊值如 proprietary 或 unlicensed。
所以它不能直接用于法律合规审计，仅适合快速扫一眼“用了哪些包、作者标称了什么许可”。
怎么用 composer licenses 导出可读的依赖+许可证列表
默认输出是表格形式，难进 CI 或做后续处理。加 --format=json 或 --format=plain 才方便解析：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer licenses --format=json > licenses.json：输出 JSON，含name、version、license、homepage等字段，适合脚本读取 -
composer licenses --format=plain > licenses.txt：纯文本制表符分隔，可用awk或 Excel 打开 - 加
--no-dev排除开发依赖，避免把phpunit这类工具计入最终分发清单 - 注意：如果项目用了
path类型仓库或package自定义包，license字段必须手动在composer.json里补全，否则输出为空
为什么 composer licenses 显示的 license 值不可信
Composer 不校验许可证真实性，只原样读取 composer.json。常见问题包括：
- 包作者写了
"license": "MIT"，但项目根目录没有LICENSE文件，或文件内容与 MIT 不符 - 用了
dev-master或dev-main分支，composer.json中的license可能过期，而composer licenses仍照搬旧值 - 某些包（如私有包）设为
"license": "proprietary"，但未提供任何使用条款，这在开源分发中属于高风险项 -
license字段支持多值（如"MIT", "Apache-2.0"），但composer licenses输出时会合并成字符串，丢失结构，无法自动判断是否满足“强 copyleft”限制
真正合规需要补什么动作
composer licenses 是起点，不是终点。要满足常见开源合规要求（如 GPL 传染性检查、许可证兼容性判断），还得：
- 对每个包，人工或用工具（如
FOSSA、SCANOSS）扫描源码，确认实际 LICENSE 文件存在且内容匹配 - 识别出
GPL-2.0-only、AGPL-3.0-only等强限制许可证，评估是否允许在你的产品中使用 - 注意
license字段里的OR/AND关系——例如"MIT OR Apache-2.0"表示可任选其一，但"MIT AND BSD-3-Clause"需同时满足两者 - 如果项目要打包分发，需额外收集每个包的完整 LICENSE 文本（
composer licenses完全不提供这个），通常得靠composer install --no-dev && find vendor/ -name 'LICENSE*' -o -name 'COPYING*'配合整理
许可证字段写得再整齐，代码里混进一个没声明的 GPL 模块，整份清单就失去意义。别只盯着 composer.json 看。
