查反向依赖应使用 composer show --who，它直接扫描已安装包的 require 和 require-dev 字段，列出显式声明依赖该包的所有包；必须小写全名，支持 --no-dev 控制是否包含开发依赖，结果仅显示一级上游。
查反向依赖关系，用 composer show --who，不是 composer why，更不是已弃用的 composer depends。
查谁直接 require 了某个包
这是最常见、最干净的反向依赖查询场景。composer show --who 直接扫描所有已安装包的 require 和 require-dev 字段，列出所有“显式声明依赖它”的包。
- 必须写全小写包名：
composer show --who psr/log，写成PSR/Log或psr-log都会报Could not find package - 默认包含开发依赖；若只关心生产环境，加
--no-dev：composer show --no-dev --who psr/log - 输出结果只显示一级上游：比如
monolog/monolog → psr/log，不会继续往上翻到laravel/framework - 如果结果为空，不代表没人用——可能是通过
provide（如psr/log-implementation）虚拟提供，此时得回看composer show -t .全局树
查“为什么装了这个包”并溯源到自己项目
当你要确认某包是不是自己 composer.json 里写的，或想理清完整引入路径，composer why --tree 是唯一选择。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须确保该包已安装在
vendor/下，否则返回No dependencies；可用ls vendor/psr/log快速验证 - 加
--dev才能查require-dev引入的链路，例如测试工具拉进来的sebastian/exporter - 输出末尾出现
your-project-name dev-main，才说明最终源头是你自己的composer.json - 如果链路在中间断掉（比如停在
symfony/console就没了），大概率是它通过provide psr/log声明，没继续解析下去——这不是 bug，是 Composer 的虚拟包机制
别碰 composer depends，它不可靠
composer depends 是实验功能，默认关闭，且行为高度受限。2.4+ 版本需先执行 composer config experimental.show-depends true，但即便开启，对 provide、replace、path 类型仓库支持极差，容易漏判。
- 它只扫描你项目根目录的
composer.json，不递归读取vendor/中每个包的依赖声明 - 不加
-r（递归）时，只显示顶层require，完全看不到间接卡版本的包 - 报
Command "depends" is not defined？说明 Composer 版本低于 2.5，别折腾，换composer show -t手动向上翻 - 官方早已把可靠能力收进
composer show --who和composer why --tree，没必要绕弯
真正容易被忽略的是：反向依赖 ≠ 运行时类加载路径。看到 composer show --who psr/log 返回了 monolog/monolog，不代表 PHP 加载 Psr\Log\LoggerInterface 时一定走它的 autoload。最终起作用的是 autoload 注册顺序和命名空间映射是否生效——这点必须结合 vendor/composer/autoload_classmap.php 或 dump-autoload -o 后的行为验证。
