composer why 找不到已安装包是因为它只解析 composer.lock 中的依赖关系，不扫描 vendor/ 目录；需确认包名是否存在于锁文件、区分 dev 依赖、检查 replace/provide 限制及插件干扰。

为什么 composer why 找不到我装了的包？

不是命令坏了，而是它只查 composer.lock 里的依赖图，不扫 vendor/ 目录——哪怕你 rm -rf vendor/ 后没重装，why 也会报 “Package not found”。

• 先运行 composer show 确认包名是否真在锁文件里（注意大小写、斜杠，monolog/monolog ≠ monolog/monolog-dev）
• 如果包是用 composer require --dev 装的，默认不显示，必须加 --dev 参数
• 用了 replace 或 provide（比如用 psr/log-implementation 替代具体日志实现），why 不会追溯到提供方，只会查显式 require
• 某些插件（如旧版 hirak/prestissimo）可能干扰解析，可临时加环境变量：COMPOSER_DISABLE_XDEBUG=1 composer why xxx

为什么 composer why monolog/monolog 输出是 root requires？

说明这个包是你自己在 composer.json 的 require 或 require-dev 里直接写的，不是被其他包带进来的——它没有上游依赖者，只有下游使用者。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 想查“谁在用它”，得换命令：composer depends monolog/monolog（注意是 depends，不是 why）
• why 不支持通配符，composer why monolog/* 必然失败
• 如果输出带 [dev] 标记，代表它是通过开发依赖链引入的，上线部署时若用了 --no-dev，这个包不会被安装

怎么看出是哪个包拖住了版本升级？

composer why 默认只返回一条最短路径，但真正卡住版本的，往往藏在某个冷门 dev 包或过时的间接依赖里。

• 先执行 composer why monolog/monolog，看谁写了约束（比如 some/package requires monolog/monolog ^1.0）
• 再用 composer show some/package 查它的 require 字段，确认是否真锁死了版本
• 想看完整路径，用 composer why --tree monolog/monolog（Composer 2.2+），或更彻底的 composer depends --tree monolog/monolog（2.5+）
• 多个路径并存时，why 只返回字典序最小的一条，别以为没别的了

composer why 和 composer why-not 别混用

why 解释“为什么装了”，why-not 解释“为什么装不上”——它们解决的是完全相反的问题。

• 遇到 composer update 报错，错误信息里一定有类似 Conclusion: don't install monolog/monolog 2.10.0 这样的否定句，把这行里的包名和版本复制出来，喂给 composer why-not
• why-not 不修改项目，只是模拟安装，可以放心试；但它不查 conflict 规则以外的逻辑，比如平台配置（"php": "8.2"）与实际环境不符时，它可能不提示
• why-not 支持 -r json 输出，适合脚本解析；而 why 没有 JSON 模式

依赖图不是静态快照，它受 composer.lock、平台配置、require-dev 开关、甚至 Xdebug 是否启用共同影响。查不到不等于不存在，只是当前上下文里它没被“选中”。