composer show -t是当前唯一开箱即用、无需插件的依赖树命令，必须指定包名（如.代表当前项目），输出中括号内版本为实际安装版本，非composer.json约束版本。
composer show -t 是唯一开箱即用、无需插件的依赖树查看方式。别折腾 composer tree 或 composer graph，它们根本不存在——Composer 官方没实现，装了插件也大概率和当前版本冲突。
为什么 composer show -t 输出乱得没法看
它靠空格缩进表示层级，不标版本号、不区分 require 和 require-dev、不折叠重复路径，Laravel 项目一跑就是上千行。你不是眼花，是工具设计本就不为“看清全貌”服务。
- 加
--no-dev过滤掉 phpunit、phpstan 这类开发依赖，能砍掉 30%~50% 的干扰节点 - 终端宽度不够时缩进换行错位，用
composer show --no-dev -t . | less -S固定列宽浏览 - 想查某个包被谁拉进来？直接
composer show --no-dev -t guzzlehttp/guzzle，从它开始向下展开，别扫全量 - 输出里带
[dev-master]或[7.8.1]括号内容，是你实际安装的版本，不是composer.json写的约束；看到v6.5.8但写了"^7.0"，说明有其他包强制降级了它
composer why 和 composer show --who 才是真·排障主力
依赖树是“全景图”，但你真正需要的往往是一条链：谁在拖旧版？哪行 require 引入了它？这时候树形输出反而低效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer why monolog/monolog告诉你哪些顶层包显式或隐式要求它，以及满足的约束（如^2.0） - 加
--tree才能溯源到你自己项目的composer.json：composer why --tree monolog/monolog，末尾出现your-project-name dev-main才算定位成功 -
composer show --who psr/log查“谁直接声明依赖了它”，结果为空 ≠ 没人用 —— 可能是通过虚拟包（如psr/log-implementation）间接提供，此时得回看全量树 -
--no-dev必须放在命令参数前面，composer why --no-dev monolog/monolog才有效；composer why monolog/monolog --no-dev会被忽略
可视化图不是“更高级”，而是“换工具链”
要出 PNG/SVG/HTML 图，必须脱离 Composer 命令本身，引入 Graphviz + 第三方工具。没有“一键生成”的魔法，只有明确分工：
- 系统先装
graphviz：brew install graphviz（macOS）、apt install graphviz（Ubuntu），否则dot -V都报错 - 推荐插件
markuspoerschke/composer-dependency-graph：全局安装后，composer-dependency-graph --format=png --output=deps.png直接出图；加--with-dev才包含require-dev - HTML 模式生成的页面不能双击打开，会因 CORS 失效；要用
python3 -m http.server 8000起本地服务再访问 - 导出 DOT 文件自己渲染更可控：
composer show --format=json --recursive获取完整依赖数据，再用脚本转 DOT；注意过滤掉dev-分支和self.version占位符，否则dot语法报错
最易被忽略的一点：所有可视化方案展示的都是 composer.lock 解析后的**实际安装结构**，不是 composer.json 里写的声明式依赖。如果你刚改了 composer.json 但没 composer update，图里压根不会反映变更。
