Composer 本身不内置生成完整许可证报告的功能，需借助 composer-licenses 插件递归解析所有依赖并标准化许可证字段，生成 JSON/HTML 报告；它解决 composer show --licenses 仅显示顶层依赖、忽略传递依赖及不解析复合许可证等问题，但对 UNLICENSED 或私有 fork 仍需人工核查许可证文本与合规性。
Composer 本身不内置生成完整许可证报告的功能，但通过 composer show --licenses 或第三方插件可导出结构化数据——关键在于选对工具、处理嵌套依赖和识别模糊许可证声明。
用 composer-licenses 插件一键导出 JSON/HTML 报告
这是目前最可靠的方式，它会递归解析所有依赖（含 require-dev），并尝试标准化许可证字段（如把 MIT、mit、MIT License 统一为 MIT）。
- 安装插件：
composer global require aqueduct/composer-licenses
- 生成 HTML 报告（含超链接和分类）：
composer licenses --format=html > licenses.html
- 生成机器可读的 JSON（便于后续合规扫描）：
composer licenses --format=json > licenses.json
- 注意：某些包在
composer.json中只写"license": "proprietary"或留空，该插件会标为UNLICENSED，需人工核查
为什么 composer show --licenses 不够用？
它只显示顶层依赖的许可证，完全忽略 vendor/ 下的传递依赖（transitive dependencies），而合规检查恰恰最关注这些底层库（比如 symfony/polyfill、psr/log）。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 执行
composer show --licenses后，你看到的只是monolog/monolog的许可证，不会看到它所依赖的psr/log或phpoption/phpoption - 它不解析
license字段中的复合表达式，例如"Apache-2.0 OR MIT"会被原样输出，不拆解为可选条款 - 不校验许可证文本是否存在（有些包声明了
MIT却没附带LICENSE文件）
手动补全缺失许可证文件的检查逻辑
即使插件报告了许可证类型，也必须验证对应文本是否真实存在于包内——很多包的 composer.json 声明与实际不符，或遗漏 LICENSE 文件。
- 检查路径优先级：
vendor/{vendor}/{package}/LICENSE*→LICENSE.md→LICENSE.txt（大小写不敏感） - 对
UNLICENSED或proprietary的包，进入其vendor/目录，运行：grep -i "copyright\|permission\|grant" vendor/{vendor}/{package}/*.{md,txt,html} 2>/dev/null | head -5 - 特别注意私有 fork：如果项目中使用了
"repo-url": "git@..."类型的自定义源，composer-licenses默认跳过，需先用composer archive导出再人工审计
真正耗时的不是生成报告，而是确认每个 UNLICENSED、unknown 或 GPL-2.0-only 条目是否被业务场景允许——尤其是当你的产品要闭源分发时，一个未被识别的 GPL 依赖可能直接导致法律风险。
