composer licenses 非原生且版本受限，仅 Composer 2.2.0+ 支持；稳定可用的是 composer show，但需 vendor 已安装，且不校验 LICENSE 文件真实性，合规自查必须人工核对原始 LICENSE 内容。
没有“一键查协议”的原生命令，composer licenses 在多数环境根本不存在；真正可用、跨版本稳定的只有 composer show，但它只读字段、不校验、不解析 LICENSE 文件——合规自查必须手动补上文件核对这一步。
为什么 composer licenses 常常报错？
它只在 Composer 2.2.0+ 中原生存在，而大量 CI 镜像（如 GitHub Actions 默认 PHP 环境）、Docker 基础镜像、企业私有部署仍停留在 2.1.x。运行即报：Command "licenses" is not defined。更常见的是：你看到的文档来自已废弃插件（如 zicht/composer-license-plugin），和当前 Composer 无关。
- 查版本：
composer --version，低于 2.2.0 就别试composer licenses - CI 中需显式指定版本，例如 GitHub Actions 里加
composer-version: '2.5' -
composer licenses --format=json输出是 JSON 数组（如[{"name":"monolog/monolog","license":"MIT"}]），不是对象，用.packages[]会报错，得用.[].name这类路径
composer show 怎么用才不漏信息？
它是唯一跨版本稳定、不依赖插件、不联网、只读 vendor/ 下真实 composer.json 的命令，但前提是 vendor/ 必须已就位——没执行过 composer install 或 composer update，composer show monolog/monolog 直接报 Package not found。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查单个包最准：
composer show monolog/monolog，字段值原样来自本地文件，不归一、不提示歧义 - 批量导出必须走 JSON：
composer show --no-dev --format=json，再用jq -r '.packages[] | "\(.name)\t\(.version)\t\(.license // ["UNKNOWN"] | join(" | "))"' - 通配符有限但可用：
composer show monolog/*可列 monolog 生态，但symfony/*可能漏掉 polyfill 类子包——它们不在composer.json的require里显式声明 - 别用
grep license解析文本输出：遇到数组型 license（如["MIT", "Apache-2.0"]）会被切碎，漏掉第二个值
看到 "license": "MIT" 就能上线？
不能。这个字段是作者自由填写的字符串，Composer 不校验真实性、不下载 LICENSE 文件、不比对内容。SPDX 官方只认 "MIT"，写成 "MIT License" 或 "The MIT License" 在 Composer 2.5+ 会直接报错，Packagist 显示 ❓。
-
"SEE LICENSE IN LICENSE.md"：composer show绝不会打开该文件，你得手动进vendor/monolog/monolog/LICENSE.md确认全文是否标准 MIT 文本 -
["MIT", "GPL-3.0-only"]：没说明是“二选一”还是“同时满足”，法律效力天差地别，必须查原始仓库 LICENSE 文件和集成方式 -
"proprietary"或空值：不是“默认安全”，而是法律盲区，法务介入前不能上线 - URL 形式 license（如
"https://example.com/LICENSE"）：composer show不访问网络，也不验证链接有效性，必须人工点开确认
真要控风险，必须补三件事
自动化工具只能筛出明显问题，绕不开人审的关键环节：
- 装插件读真实 LICENSE 文件：
composer require --dev composer/license-checker，再跑vendor/bin/license-checker——它会逐个打开vendor/下每个包的 LICENSE 文件，比对内容是否匹配声明 - CI 中加硬检查：比如只允许白名单协议，其他一律失败：
composer show --no-dev --format=json | jq -r '.packages[] | .license // ["UNLICENSED"] | .[]' | grep -qE '^(MIT|Apache-2.0|BSD-3-Clause)$' || (echo "non-compliant license found"; exit 1) - 人工核对 LICENSE 文件原文：真正有法律效力的是源码根目录下
LICENSE或LICENSE.md的全文内容，不是composer.json里的字符串——尤其当字段值为模糊描述、URL 或多许可数组时，这步无法跳过
最容易被忽略的点是：composer show 和 composer.lock 解析结果可能不一致，前者反映当前 vendor/ 状态，后者记录解析快照；而无论哪种，都不等于 LICENSE 文件本身——合规闭环的最后一公里，永远需要人眼确认。
