composer why 用于反向查询依赖：给定包名，显示当前项目中直接或间接依赖它的包。可解决删包影响评估、升级故障定位、安全漏洞溯源等问题，支持直接依赖（默认）和递归依赖（-r 参数），但要求包名准确且项目处于正确根目录。
composer why 是什么，能解决什么问题
composer why 用来反向查依赖：给定一个包名，它告诉你「当前项目里哪些包直接或间接依赖了它」。这不是看 composer.json 里写了谁，而是实际安装后形成的依赖链快照。
常见使用场景包括：
- 想删掉某个包，但不确定会不会影响其他包
- 升级失败时怀疑是某依赖包拖了后腿，需要定位源头
- 审计安全漏洞（比如发现
monolog/monolog有 CVE，想知道谁拉进了它）
怎么用 composer why 查直接依赖
默认只显示直接依赖者（即 composer.json 中明确 require 的包），不展开传递依赖：
composer why monolog/monolog
输出类似：
laravel/framework v10.48.12 requires monolog/monolog (^2.9|^3.0)
注意点：
- 包名必须写全，大小写敏感，比如
guzzlehttp/guzzle不能写成guzzle - 如果提示
Package not found，说明该包没被安装进vendor/（可能被 require-dev 隔离，或根本没装） - 不支持通配符或模糊匹配
怎么查完整依赖链（含间接依赖）
加 -r（recursive）参数：
composer why -r symfony/console
输出会逐层展开，例如：
myapp/myproject dev-main requires laravel/framework (^10.0) laravel/framework v10.48.12 requires symfony/console (^6.2|^7.0)
关键细节：
- 递归深度无上限，但实际中一般 3–4 层就到顶了
- 若某包被多个路径引入，
composer why -r只显示第一条可追溯路径，不是全部路径 - 想看所有路径？得用
composer depends --tree（Composer 2.5+），但该命令尚未稳定，部分版本不支持
为什么 sometimes composer why 返回空或报错
最常踩的几个坑：
- 当前目录不在 Composer 项目根目录（即没有
composer.lock或vendor/），会报Could not find package - 包被
replace或provide机制覆盖（比如psr/log被monolog/monolog提供），此时composer why psr/log会失败，得换查提供者 - 使用了
platform配置（如"ext-curl": "7.85.0"），这些虚拟扩展无法被why追踪 - 包名拼错，或用了别名（比如
illuminate/support别名是laravel/support，但composer why laravel/support找不到）
依赖关系不是静态树，而是解析锁文件后的动态快照。哪怕 composer.json 里没写，只要 composer.lock 里存在且被某依赖拉入，why 就能查到。
