composer depends 查不到包需确认四点：是否在项目根目录、composer版本≥2.2、目标包被直接声明、是否需用--recursive查多级依赖；否则可查vendor/composer/installed.json。
composer depends 查不到包？先确认是否在项目根目录运行
执行 composer depends 前必须处于 composer.json 所在的项目根目录，否则会报错或返回空结果。它不支持跨项目、不支持全局模式，也不读取 vendor 目录外的锁文件。
- 错误现象：
Command "depends" is not defined.—— 说明你用的是 Composer 1.x，该命令仅在 Composer 2.2+ 中可用 - 正确检查方式：
composer --version，低于2.2.0需升级：composer self-update - 如果项目未安装依赖（即没有
vendor/或composer.lock），depends仍可工作，但它只分析composer.json的声明依赖，不解析实际安装树
composer depends foo/bar 返回空？可能是依赖未被直接声明
composer depends 只显示「直接声明」了该包的项目或包，不会向上追溯传递依赖（transitive dependency）。比如 A → B → C，你在 C 上运行 composer depends c/d，只会显示 B，而不会显示 A —— 即使 A 最终用到了 C。
- 常见场景：你想知道哪个业务包拖进了
monolog/monolog，但结果为空 —— 很可能它是被某个中间 SDK（如acme/logging-sdk）声明的，而你的项目只写了"acme/logging-sdk": "^1.0" - 验证方法：进
vendor/acme/logging-sdk/composer.json查看其require字段是否含目标包 - 想查完整链路？得用
composer show -t反向展开，或配合grep -r "monolog/monolog" vendor/*/composer.json
composer depends --tree 和 --recursive 的区别很关键
--tree 不是递归查依赖者，而是把「每个依赖者」自己的依赖树也打印出来；--recursive 才是真正向上翻多层（默认只查一级）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer depends monolog/monolog：只列出直接 require 它的包（一级） -
composer depends monolog/monolog --recursive：列出 require 它的包，以及 require 那些包的包（二级），依此类推 -
composer depends monolog/monolog --tree：对每个一级依赖者，额外执行一次composer show -t {package}，展示它的整个依赖结构 —— 这个输出非常长，慎用 - 性能影响：--recursive 在大型项目中可能明显变慢，因为要反复解析多个
composer.json；--tree 更重，还会触发依赖图构建
反向查找失败时，vendor/composer/installed.json 是最后防线
当 composer depends 因各种原因不可用（如 Composer 版本太低、权限问题、或依赖关系被 patch 修改过），可以手动查 vendor/composer/installed.json —— 它是 Composer 实际安装状态的权威快照。
- 该文件里每个包都有
require字段，记录它自己声明依赖了谁；反过来，你可以写个脚本遍历所有已安装包，收集哪些包的require包含目标名 - 注意字段名是
name（如"monolog/monolog"），不是dist/ref或source/reference - 真实案例：某私有包用了 path repo + symlink，
depends漏掉了它，但installed.json里仍有完整记录
复杂点在于：Composer 的依赖解析受 platform config、stability flags、require-dev 开关等影响，depends 只反映当前 lock 文件生效的视图 —— 如果你改过 composer.json 但没 update，它就看不到新声明的依赖关系。
