composer depends 查反向依赖，如 composer depends monolog/monolog；composer tree --format=tree 显示完整正向依赖树，需 Composer 2.5+ 支持。
composer 本身不直接生成可视化依赖树，但能输出结构化依赖关系；想看“谁依赖了谁”，关键不是 composer show，而是用 composer depends 和 composer tree
怎么查某个包被哪些其他包依赖（反向依赖）
开发中常遇到：想删掉 monolog/monolog，但不确定有没有其他包偷偷依赖它。这时 composer depends 是唯一可靠手段。
-
composer depends monolog/monolog—— 列出直接依赖它的包（不含递归） -
composer depends --tree monolog/monolog—— 显示完整依赖路径，比如laravel/framework → illuminate/log → monolog/monolog - 注意：
composer depends不支持通配符，也不能查本地未安装的包；如果提示 “Package not found”，说明该包没在vendor/里或没被当前composer.json解析到
怎么生成当前项目的完整依赖树（正向展开）
composer tree 是最接近“依赖树”的命令，但它默认只显示顶层 require 的包及其第一层子依赖。真正要看到全貌，得加参数。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer tree --format=tree（Composer 2.5+）—— 输出缩进式树形，层级清晰 -
composer tree --format=json—— 输出 JSON，适合脚本解析，字段含name、version、requires - 旧版 Composer（--format，只能用
composer show --tree，但会混入 dev 依赖，且不区分 require / require-dev；若只想看生产依赖，先运行composer install --no-dev再执行
为什么 composer show 容易误判依赖关系
composer show 看起来像依赖列表，其实只是已安装包的摘要，不体现依赖方向和嵌套层级。
-
composer show默认列出所有已安装包，包括require-dev中的（如phpunit/phpunit），容易当成运行时依赖 -
composer show vendor/package只显示该包自己的 require 列表，不告诉你项目里谁拉进了它 —— 这是正向 vs 反向的根本混淆点 - 更隐蔽的问题：某些包通过
replace或provide声明“替代”另一个包（如psr/log-implementation），composer show不会标出这种逻辑依赖，只有composer depends能穿透识别
导出依赖图谱供外部工具分析（如安全扫描）
CI/CD 或 SCA 工具需要机器可读的依赖快照，别手写解析 composer.lock，Composer 自带标准输出格式。
-
composer show --format=json --no-dev—— 生产环境最小依赖集，JSON 结构稳定，字段name、version、require都可用 -
composer.lock文件本身是权威来源，但它是锁定文件，含哈希和平台信息；解析时注意packages（生产）和packages-dev（开发）两个数组 - 避免用
composer outdated当依赖源——它只对比版本，不反映实际安装结构；尤其在部分更新后，outdated可能漏掉已被降级但仍在vendor/中的旧包
依赖关系不是静态快照，而是解析器根据 composer.json + composer.lock + 当前平台约束动态计算的结果；哪怕同一份代码，composer install 在不同 PHP 版本下生成的树都可能不同。查依赖时，永远以当前 vendor/ 状态为准，而不是靠记忆或文档猜测。
