最直接方法是运行composer show --tree monolog/monolog，它递归展开该包所有已安装的下游依赖，缩进表示层级关系，但要求包必须已通过composer install实际安装，否则报“package not found”。
composer show --tree 看依赖树最直接
想快速知道某个包（比如 monolog/monolog）装了哪些下游依赖，直接运行：
composer show --tree monolog/monolog。它会递归展开所有 require 的包，缩进表示层级关系。注意：这个命令只显示当前已安装的包构成的树，如果包没装过（
composer install 没跑），会报错“Package not found”。
composer depends 查谁在依赖某个包
当你想删掉一个包但不确定是否被其他包间接引用，用 composer depends 反向查依赖源更安全。例如：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer depends symfony/polyfill-mbstring。它列出所有直接或间接 require 该 polyfill 的包。默认只显示一级依赖，加
-t（transitive）参数才显示完整路径，比如：composer depends -t symfony/polyfill-mbstring。
依赖冲突时 tree 输出不可信
composer show --tree 展示的是“当前 lock 文件里记录的解析结果”，不是实时 resolve 过程。如果 composer install 失败、或你刚改了 composer.json 但没更新 lock，tree 显示的结构可能和实际安装行为不一致。真正可靠的依赖图，得靠：
composer update --dry-run --no-progress，看它实际打算怎么拉取和降级——尤其当出现
Root composer.json requires xxx but xxx is locked to yyy 这类错误时，tree 信息反而会误导。
可视化依赖图需要额外工具
Composer 原生命令不生成图形。想导出 SVG 或交互式图谱，得借助第三方：
- 用
composer global require bitexpert/composer-graph安装后，执行composer graph --format=svg > deps.svg - 或者用
phpstan/dependency-injection配合phpstan analyse --debug抽取部分依赖关系（适合分析 autoloading 层） - 注意：所有图形化工具都依赖
composer.lock，且对循环 require、path repos、vcs repos 支持不一，导出前先composer update --lock确保 lock 文件最新
composer update 后，哪怕只改一行版本号，整个树结构都可能重排——别只盯着 show --tree 看，关键路径要结合 --dry-run 和 lock 文件 diff 来验证。
