查反向依赖应使用 composer show --who，它直接扫描已安装包的 require 和 require-dev 字段，列出显式声明依赖该包的所有包；必须小写全名，支持 --no-dev 控制是否包含开发依赖，结果仅显示一级上游。
直接结论：用 composer show --who，不是 composer why，更不是 composer depends。 它最准、最稳、不依赖版本新旧，也不受 provide 虚拟包干扰。
为什么 composer why 经常查不到“谁引用了我”
它查的是「谁最终导致这个包被安装」，不是「谁在 composer.json 里写了 require」。结果可能跳过你真正关心的源头，尤其当链路中存在 psr/log-implementation 这类虚拟提供者时，why 会静默中断。
-
composer why psr/log可能只返回topthink/framework，但你真正想确认的是：这行是不是你自己加的？ - 如果包只在
require-dev里（比如被phpunit/phpunit引用），默认不查，得额外加--dev - 没装到
vendor/下（比如刚 clone 项目还没composer install），why直接报Could not find package
composer show --who 怎么用才不漏掉关键信息
它直接扫描所有已安装包的 composer.json 中的 require 和 require-dev 字段，输出的是「谁明文写了这行」，干净利落。
- 查生产环境谁用了
monolog/monolog：composer show --who --no-dev monolog/monolog - 查全部来源（含开发依赖）：
composer show --who monolog/monolog - 包名必须全小写、带 vendor 名，
Monolog/monolog或monolog都会失败 - 结果为空 ≠ 没人用 —— 可能是通过
provide间接提供，此时应回头跑composer show -t . | grep monolog看全局结构
遇到 composer depends 报错或空结果，别硬扛
这个命令在 Composer composer.json，完全不读 vendor/ 里的嵌套依赖，对 provide 更是无感。
-
Command "depends" is not defined→ 先跑composer --version，低于 2.5 就升级：composer self-update - 返回空列表 → 说明目标包没出现在你项目的
composer.json里，它大概率是被某个已安装包间接拉进来的 - 哪怕升级到 2.9.6，
depends依然不会告诉你guzzlehttp/guzzle是被spatie/laravel-backup带进来的 —— 那得靠composer why guzzlehttp/guzzle
真正容易被忽略的点是：依赖关系不是静态的，它严格绑定当前 composer.lock 的解析结果。同一份代码，本地没 composer update，CI 上跑了，show --who 输出就可能完全不同。
