composer show 是唯一原生靠谱的起点，它读取 vendor/ 下已安装包 composer.json 中的 license 字段，不查网络、不解析 license 文件、不依赖插件，输出即源头声明。
composer licenses 命令不是 Composer 内置命令，执行必报错 —— 别在 CI 脚本里写它，也别怪自己装错了。 官方从未实现该命令，所有文档中出现的 composer licenses 都指向第三方插件，且默认不生效。真正开箱即用、无需额外安装、结果最稳定的起点只有一个：composer show vendor/package-name。
为什么 composer show 是唯一原生靠谱的起点
它读取的是 vendor/ 下已安装包的 composer.json 中的 license 字段，不查网络、不解析 LICENSE 文件、不依赖插件，输出即源头声明。
- 必须已运行过
composer install或composer update，否则vendor/为空，composer show报Package not found - 支持通配符：如
composer show monolog/*可一次列出整个 monolog 生态的license值 - 字段值可能是空、
proprietary、SEE LICENSE IN LICENSE.md或数组（如["MIT", "Apache-2.0"]）——composer show全部照搬，不做归一化 - 不处理传递依赖：只查
composer.json中显式声明的包，symfony/polyfill-intl-idn这类子依赖完全不会出现
composer licenses --format=json 实际是谁在干活
这个命令能跑通，说明你本地已安装了 zicht/composer-license-plugin。它才是背后真正递归扫描所有依赖（含 require-dev 和传递依赖）、尝试标准化许可证名（如把 MIT License 统一为 MIT）、并输出结构化 JSON 的工具。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 安装方式：
composer require --dev zicht/composer-license-plugin - 导出全量清单：
composer licenses --format=json > licenses.json - 查 GPL 类风险：
jq -r '.[] | select(.license | test("GPL|AGPL|LGPL"; "i")) | "\(.name) \(.version) \(.license)"' licenses.json - 对私有 fork（如
"repositories": [{"type": "vcs", "url": "git@"}]）默认跳过，得先composer archive导出再人工审计
别把 composer audit 当成许可证检查工具
composer audit 只查 CVE、废弃包和连接失败，**完全不分析 license 字段，也不判断兼容性**。它的输出里哪怕出现 “License conflict”，那也是误标——官方 audit 命令压根没这逻辑。
-
composer audit --ignore=CVE-2021-12345对 MIT/GPL 冲突毫无影响 -
"abandoned": "fail"配置跟许可证类型无关 - CI 中只跑
composer audit就认为过了合规关，等于把法律审查交给一个不干这事的命令
真正难的不是命令怎么敲，而是看到 "license": "SEE LICENSE IN LICENSE.md" 时得手动打开对应文件核对全文，遇到空值、unlicensed、proprietary 时不能跳过，还得确认 SPDX 标识符是否标准（比如 MIT 合规，mit 或 The MIT License 不算）。这些没法自动化，得人盯。
