最可靠方式是运行 composer show vendor/package-name 查 license 字段；未安装包无法查询，packagist 显示的是最新版而非本地实际安装版本，composer.lock 才是法律意义上生效的许可证依据。
composer show 如何快速查某个包的许可证
直接运行 composer show vendor/package-name，输出里会包含 license 字段。这是最轻量、最可靠的方式，不需要额外插件或解析 json。
- 如果只记得部分包名，可用
composer show（不带参数）列出全部已安装包，再 grep 过滤：composer show | grep -A 2 "monolog" - 注意：有些包在
composer.json里写的是"license": "MIT"，但也有写"license": ["MIT", "apache-2.0"]或"license": "proprietary"，composer show会原样显示，不会自动归一化 - 未安装的包无法用这个命令查——
composer show只读vendor/下已安装的元数据，不是实时查 Packagist
composer licenses 命令为什么经常没反应
composer licenses 是一个内置命令，但它默认只输出「项目根目录下 composer.json 直接 require 的包」的许可证汇总，不会递归展开所有依赖，更不会检查 dev-dependencies（除非加 --dev）。
- 常见误操作：运行后空白或只输出几行——大概率是因为你没加
--tree或--format=json，它默认只列顶层包，且跳过无 license 字段的包 - 想看全量依赖的许可证，得加
--tree：composer licenses --tree，否则连symfony/console这种间接依赖都不会出现 - 该命令对 license 字段为空、写成
"UNLICENSED"或"proprietary"的包，会直接跳过，不报错也不提示
如何批量导出所有依赖的许可证用于合规审计
靠人工翻 composer show 不现实，真正能落地的是解析 composer.lock ——它结构稳定、字段明确，且含所有已安装包（含嵌套依赖）的 license 值。
- 用 PHP 脚本最稳妥：
json_decode(file_get_contents('composer.lock'), true)['packages']，遍历每个数组项的license键（注意：有些包把 license 放在packages-dev里，需分别处理） - 一行 shell 也能应急：
jq -r '.packages[].license // [] | .[]?' composer.lock | sort -u，但 jq 不能处理空 license 或数组嵌套时的 NULL 安全访问，容易漏 - 警惕
license字段值为null、[]或字符串"unknown"的包——这些不是命令坏了，是包作者根本没填，得人工确认
packagist.org 上查许可证和本地结果不一致怎么办
因为 Packagist 显示的是该包「最新稳定版 composer.json」里的 license 字段，而你本地装的可能是旧版本、dev 分支、甚至被 fork 修改过的私有源包。
- 先确认版本：
composer show vendor/package-name输出的versions行，比如* 3.4.2，再去 Packagist 搜对应 tag 的源码，看那个 commit 里的composer.json - 私有包或 VCS 包（如
"type": "vcs"）的 license 完全以你 clone 下来的代码为准，Packagist 根本不索引它们 - 某些包在不同版本间改过 license（比如从 MIT 改成 Apache-2.0），
composer.lock记的是实际安装版本，这才是法律意义上生效的协议
合规这事，关键不在“有没有 license 字段”，而在“你实际打包分发时，到底带了哪个版本的代码”。composer.lock 是唯一可信来源，别信 Packagist 页面，也别信 README 里写的“License: MIT”。