composer depends 默认禁用且仅扫描声明依赖，需全局启用实验配置 experimental.show-depends 才生效；它不解析已安装包的依赖、跳过 provide/replace/path 类型，故常无输出；推荐改用 composer show --who 或 composer why -t 等稳定命令。
composer depends 在大多数项目里根本查不到东西，不是你用错了，是它默认关闭、版本不对、或压根不适用当前场景。
composer depends 命令为什么经常没反应
这个命令从 Composer 2.4 开始作为实验功能引入，但默认是禁用的。即使你升级到了 2.5+，运行 composer depends vendor/package 依然可能报错或静默返回空——因为：
- 没开启实验配置：
composer config --global experimental.show-depends true才能启用 - 只扫描
composer.json中require和require-dev字段，不解析vendor/下已安装包的依赖声明 - 遇到
provide（如"psr/log": "*"）、replace或本地path仓库时，会直接跳过，不回溯 - Windows PowerShell 用户若用
grep过滤，会失败；得换sls
替代方案：用 composer show --who 更可靠
composer show --who 不依赖实验配置，直接读取所有已安装包的 composer.json 文件里的 require 字段，结果确定、不漏判：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查谁直接依赖
psr/log：composer show --who psr/log - 排除开发依赖：
composer show --who --no-dev psr/log - 注意：它只显示“第一层声明者”，比如 A → B → C，
--who只列 B；要看到 A，得配合composer show -t B往上翻 - 如果返回空，不代表没人用——可能是某包通过
"provide": {"psr/log": "*"}虚拟提供，此时必须用composer show -t . | grep -i psr/log全局扫
想看完整依赖路径？别信 --tree，用 -t 加过滤
composer depends --tree 看似合理，但实际支持差、文档混乱，且在 Composer 2.5+ 中行为不稳定。真正稳定可用的是：
-
composer show -t vendor/package-name：查看该包及其所有下游依赖（正向链） -
composer why -t vendor/package-name：查谁最终导致它被装上（反向溯源，带完整路径） - 终端太窄导致缩进错乱？加
--no-dev | less -S横向滚动：composer show -t --no-dev guzzlehttp/guzzle | less -S - 想快速定位某包在哪一层？用
grep -A 2 -B 2 "target"（Linux/macOS）或sls -Context 2 "target"（PowerShell）
真正容易被忽略的点是：Composer 的依赖解析结果取决于 composer.lock 快照、platform 配置、以及是否启用了 --no-dev。同一条命令，在 CI 环境和本地执行，输出可能完全不同——别只看命令本身，先确认 vendor/ 和 composer.lock 是不是当前上下文的真实状态。
