composer show --licenses 只显示根包许可证，因不递归扫描依赖树；需 Composer 2.5+ 的 --all 参数或手动解析 composer show --tree 输出，且 license 字段可能为空或不准确，须结合源码 LICENSE 文件人工复核。
composer show --licenses 为什么只显示部分包的许可证？
直接运行 composer show --licenses 看起来最直观，但它只列出 root package（即你项目 composer.json 中声明的直接依赖）的许可证，不会递归扫描整个依赖树。很多合规场景需要知道所有传递依赖（transitive dependencies）用的是什么 License，比如 MIT、GPL-3.0、AGPL-3.0 这类有传染性或限制条款的许可证——这时候它就漏了。
真正要扫全量，得靠 composer show --tree 结合手动过滤，或者换更可靠的工具链：
-
composer show --tree输出完整依赖树，但许可证字段不默认显示，需配合--format=json+ 解析 - 推荐用
composer licenses（来自hirak/prestissimo旧插件已弃用），现在更稳妥的是安装官方支持的composer/composer2.5+ 自带的composer show --licenses --all - 如果用的是 Composer 2.4 或更低版本，
--all参数不存在，必须升级或改用第三方工具
如何用 composer show --licenses --all 扫描全部依赖
这是 Composer 2.5+ 原生支持的命令，能递归列出所有已安装包（包括 dev 和非 dev）及其 license 字段值，不含 license 文本，只输出结构化信息，适合后续 grep 或脚本处理。
执行前确认版本：composer --version。若低于 2.5，先升级：composer self-update（注意某些企业镜像可能缓存旧版，可加 --1 或 --2 强制指定主版本）。
常用组合：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer show --licenses --all | grep -E "(GPL|AGPL|LGPL|SSPL|CC-BY)"快速定位高风险 license -
composer show --licenses --all --format=json > licenses.json导出供 CI 工具解析 - 若某包没填
license字段（常见于私有包或老旧包），输出中该字段为null，需人工核查其composer.json或源码仓库 LICENSE 文件
遇到 license 字段为空或写成 "proprietary" 怎么办？
Composer 不校验 license 字段合法性，很多包填 "license": "proprietary"、"license": ""、甚至留空，这类条目在 --licenses --all 输出里会显示为 null 或空字符串，不代表“无 license”，而是“未声明”——这恰恰是合规审计中最危险的一类。
应对方式不是跳过，而是必须追查：
- 查包的 GitHub/GitLab 仓库根目录是否存在
LICENSE或LICENSE.md - 看其
composer.json的source或dist地址，下载源码后检查真实许可文本 - 对内部私有包，确保团队统一在
composer.json中填写标准 SPDX ID（如Apache-2.0），避免写自然语言描述 - CI 流程中可用
spdx/license-list-data的 JSON 数据做校验，拒绝license字段不在 SPDX 官方列表中的包入库
为什么不能只信 composer.json 里的 license 字段？
因为 license 是作者自填字段，不强制校验，也不随代码同步更新。常见脱节场景：
- 包升级了大版本，许可证从 MIT 改成 BUSL-1.1，但作者忘了改
composer.json - fork 的私有分支修改了原始 license，但未更新 metadata
- 某些包把 license 文本放在子目录（如
vendor/foo/bar/LICENSE-3RD-PARTY），而composer.json里写的却是主 LICENSE
所以合规动作必须分两层：先用 composer show --licenses --all 快筛，再对命中高风险或空 license 的包，用 grep -r "LICENSE\|Copyright" vendor/xxx 实际验证文件内容。工具只是起点，人工复核绕不开。
