composer install本身不检测、不输出、也不校验任何授权协议信息，它仅复现composer.lock中的依赖状态；真正查license需用composer show --license（轻量稳定）或composer licenses --format=json（结构化批量分析），但所有license字段均来自维护者手动填写，不可信，必须人工核对根目录license文件内容。
composer install 本身不检测、不输出、也不校验任何授权协议信息——它只负责下载和安装包，协议检查必须用其他命令。
为什么 composer install 不显示 license 信息
该命令的核心职责是复现 composer.lock 中记录的依赖状态：解压 dist 包、写入 vendor/、生成 autoloader。它不读取、不解析、不验证任何 license 字段或 LICENSE 文件内容。
- 即使某个包在
composer.json里写了"license": "GPL-3.0"，install也完全无视 - 就算包根目录有
LICENSE文件，install阶段既不检查它是否存在，也不比对内容是否匹配字段 - 执行
composer install --dry-run或加--verbose也不会吐出协议相关日志
真正能查 license 的命令只有 composer show --license
这是最轻量、最直接的方式，结果来自 composer.lock 元数据，稳定可复现：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer show --license，输出格式为vendor/name version license - 例如：
monolog/monolog 2.9.1 MIT，doctrine/annotations 1.15.0 unknown - 若 license 字段为空或为
dev，会显示unknown或留空，这类必须人工打开对应包的源码仓库，检查根目录LICENSE文件 - 数组型声明（如
["MIT", "BSD-3-Clause"]）会被合并显示为MIT, BSD-3-Clause，但不会自动判断组合是否合规
批量筛选风险协议必须用 composer licenses --format=json
当项目依赖超过 30 个时，纯文本输出难定位 GPL、AGPL、SSPL 等需法律评估的协议：
- 执行
composer licenses --format=json > licenses.json，生成结构化 JSON，每项含name、version、license、homepage -
--format=csv是旧版插件功能，现代 Composer（2.2+）不支持，别试 - JSON 中
license为null表示该包未声明协议，必须立刻核查其源码仓库根目录是否存在LICENSE或LICENSE.md - 注意：该命令不递归分析传递依赖的协议，只列直接安装的包；也不校验 SPDX 格式合法性，比如
"MIT License"（带 License 后缀）算非法 SPDX ID，但命令照常输出
license 字段不可信，必须人工核对 LICENSE 文件
所有 composer show --license 和 composer licenses 输出的 license 值，都仅来自维护者手动填写的 composer.json，错误率高：
- 常见造假：把
Apache-2.0写成MIT，或漏填导致显示unknown - 过时风险：包已升级协议（如从 MIT 改为 MPL-2.0），但
composer.json没同步更新 - 法律效力只来自项目根目录的
LICENSE（无后缀）或LICENSE.md文件，composer.json里的字段只是元信息，不具法律约束力
真正卡住合规审查的点从来不是命令跑不跑得通，而是你有没有翻开源码仓库，亲手打开那个 LICENSE 文件，逐字确认内容是否与声明一致、是否覆盖当前使用方式。
