composer why返回“No dependencies exist”说明该包是根依赖，即直接写在composer.json的require或require-dev中；它不显示直接依赖路径是设计使然，非bug，需用composer depends查使用方或解析installed.json溯源。
composer why 不是万能的依赖溯源工具，它只展示间接依赖路径，直接写在 composer.json 里的包永远不显示原因——这不是 bug，是设计如此。
为什么 composer why vendor/package 返回 “No dependencies exist”
这几乎一定说明该包是根依赖：它被你亲手写进了 composer.json 的 require 或 require-dev 字段，而非被其他包带进来的。
- 先运行
grep -n "vendor/package" composer.json确认是否直接存在 - 若存在，
composer why就不会输出任何内容——这是正常行为，不是命令失效 - 想查它被谁“使用”，得换方向：
composer depends vendor/package（Composer 2.2+） - 如果
depends也空，说明它当前没被任何已安装包 require，只是闲置在 vendor 里
composer why 报 “Package not found” 怎么办
这个错误不是说包没装上，而是它不在 composer.lock 的依赖图中——可能已被移除、未正式 install、或仅存在于 vendor/ 但没记录。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先跑
composer show vendor/package，看是否出现在输出列表里；若无，则它根本没被 Composer 认为“已安装” - 检查是否漏了
--dev：composer why --dev vendor/package才能查require-dev引入的包 - 确认包名拼写完全一致，包括大小写和斜杠，例如
monolog/monolog≠monolog/monolog-dev - 某些私有包或
replace/provide声明的包，why无法追溯到提供方，只能看到显式 require 的包
查不到完整路径？用 composer depends --all --tree
composer why 默认只返回一条最短路径，且不展开版本约束细节。要看到所有引入者及其依赖链，必须升级到 Composer 2.2+ 并用更严格的命令。
-
composer depends --all vendor/package：强制扫描require和require-dev两部分 -
composer depends --tree vendor/package：输出树状结构，一眼看出哪个上游包在拉哪个版本 - 若仍不明确，打开
composer.lock搜索该包，找到source.reference，再反查哪个上游包的require字段匹配了这个 commit/tag - 注意：多个路径并存时，
why只返回字典序最小的一条，容易遗漏关键依赖
真正可靠的溯源方式：直接读 vendor/composer/installed.json
当命令行结果混乱、版本跳变、或 Composer 版本太旧时，installed.json 是唯一权威来源——它记录每个包实际是被谁 require 的。
- 用
jq快速提取（Linux/macOS）：jq -r '.packages[] | select(.name == "vendor/package") | .require' vendor/composer/installed.json - 输出为空 → 它是直接依赖
- 输出为对象（如
{"upstream/package": "^1.2"}）→ 这就是真实上游 - Windows 用户可用 Python 或 PowerShell 解析该 JSON，关键是别信命令输出，信文件本身
最常被忽略的一点：如果你改过 composer.json 但没运行 composer update 或 composer install，installed.json 里的 require 字段就还是旧的——它反映的是当前 vendor 状态，不是你编辑过的配置。
