composer licenses 是 Composer 2.2+ 原生命令，无需插件，依赖 vendor/ 存在；输出 license 字段不标准化，不校验 LICENSE 文件，法务审核须人工核对源码声明。
composer licenses 命令在 Composer 2.2+ 中是原生命令，但低于该版本会直接报错 Command "licenses" is not defined；它不依赖插件，也不需要提前配置——只要版本够新、vendor/ 已存在，就能立刻用。
确认你真能用 composer licenses
别被文档或旧教程带偏：这个命令不是插件，也不是社区脚本，而是 Composer 官方从 2.2 版本起才加入的内置功能。运行前先检查版本：
composer --version
输出必须是 Composer version 2.2.0 或更高。如果低于此版本，composer licenses 必然失败，且没有任何 fallback 行为——它不会退化成 composer show 或其他提示。
- 升级方式：用
composer self-update（需网络通畅）或手动下载新版 phar - CI 环境中容易忽略这点：Docker 镜像、GitHub Actions 的
php-actions/composer默认可能仍是 2.1.x - 运行前确保已执行过
composer install或composer update，否则vendor/为空，命令虽不报错但输出为空
composer licenses 的输出格式与字段含义
默认输出是纯文本，每块包含 name、version、license、authors 四行，但注意：
-
license字段值直接取自各包composer.json中的"license"键，**不做标准化处理**：可能是"MIT"、["MIT", "Apache-2.0"]、"proprietary"，甚至空字符串 - 不显示许可证文件是否存在（如
LICENSE或LICENSE.md），也不校验内容是否匹配 SPDX 标识符 - 不区分
GPL-2.0-only和GPL-2.0-or-later，法务审核时必须人工核对源码仓库原始声明 - 所有依赖（包括
require-dev中的）都会列出，除非加--no-dev
常用格式参数：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer licenses --format=json
输出为 JSON 数组，每个对象含 name、version、license、authors；适合 jq 过滤，例如只看 GPL 类：
composer licenses --format=json | jq -r '.[] | select(.license | contains("GPL")) | "\(.name) \(.version) \(.license)"'
替代方案：当 composer licenses 不可用或不够用时
如果你用的是旧版 Composer，或需要更可靠、可审计的结果（比如跳过 vendor 直接解析 lock 文件），这些方式更可控：
- 用
composer show --format=json --all：输出所有已安装包的完整信息，含license字段；但要求vendor/存在，且某些嵌套依赖可能缺失license声明 - 直接解析
composer.lock：jq -r '.packages[] | select(.license != null) | "\(.name)\t\(.version)\t\(.license | join(" / "))"' composer.lock—— 这个不依赖vendor/，也不需要composer install，但可能漏掉只在packages-dev或未 flatten 的嵌套依赖中声明的 license - 装插件
zicht/composer-license-plugin：支持--format=html生成带链接的报告，适合人工审查；但它读的是vendor/下实际文件，比解析 lock 更“真实”，也更慢
所有方法都绕不开一个事实：Composer 只信任 composer.json 里写的 license 字段，而这个字段可以是错的、空的、模糊的（如 "BSD" 而非 "BSD-3-Clause"）。真正合规检查必须结合源码仓库的 LICENSE 文件内容比对。
导出后怎么用于合规判断？
拿到 JSON 或文本清单只是第一步。关键动作是过滤和人工确认：
- 用
grep -i -E "(gpl|agpl|lgpl|copyleft|proprietary|unknown|unlicensed)"快速标出高风险项 - 对
license值为数组的包（如["MIT", "Apache-2.0"]），确认项目使用方式是否满足任一许可条件（SPDX 规范要求用OR连接，不是逗号） -
unknown不等于“安全”——它意味着该包没在composer.json声明 license，必须去 GitHub/GitLab 仓库翻原始 LICENSE 文件 - CI 中建议用
composer licenses --format=json | jq 'map(select(.license == "GPL-2.0" or .license == "GPL-3.0")) | length' | grep -q '^0$'做硬性拦截
最常被忽略的一点：许可证信息来自元数据，而非实际分发的代码文件。哪怕 composer.json 写着 "MIT"，如果对应 tag 下的源码里放的是 GPL-3.0 文本，法律上仍以源码为准。
