composer show -t 的缩进仅表示直接 require 声明关系，每两级空格代表一层依赖声明，不反映加载顺序、重要性或运行时行为；同一包在不同缩进出现说明被多路径引入，易引发版本冲突。
Composer 没有“层级嵌套”这个工程概念，所谓“层级”只是 composer show -t 输出的缩进视觉效果，它不控制加载、不决定优先级、也不影响运行时行为。
composer show -t 的缩进到底在表达什么
每两级空格缩进代表一次直接 require 声明关系。比如你在项目里 require 了 guzzlehttp/guzzle，而 Guzzle 自己的 composer.json 里写了 "psr/http-client": "^1.0"，那么 psr/http-client 就会出现在 guzzlehttp/guzzle 下方、缩进两格的位置。
- 缩进 ≠ 加载顺序：PHP 自动加载靠的是
vendor/composer/autoload_*.php里的映射表，和缩进无关 - 缩进 ≠ 重要性：
monolog/monolog出现在第 2 级或第 6 级，对 Composer 解析器来说完全等价 - 同一包在不同缩进深度重复出现，只说明它被多个上游包分别引入——这是冲突高发信号，不是“嵌套太深”的问题
为什么你改了主依赖版本，子依赖却没跟着变
因为 Composer 不是“一层一层往下装”，而是用 SAT 求解器把所有约束（你的 require、各包的 conflict、PHP 版本、platform 配置）统一建模后，一次性算出全局唯一可行解。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 你写
"laravel/framework": "10.40.0"，但某个间接依赖硬性要求"laravel/framework": "^9.0"，求解器不会妥协取交集，而是直接报错Your requirements could not be resolved - 此时
composer why-not laravel/framework:10.40才是有效排查命令，而不是反复调整composer.json书写顺序 -
composer install根本不重新解析——它只按composer.lock里已存的完整快照还原，连子依赖的子依赖都精确到哈希值
大型项目里“嵌套依赖”真正危险的地方
不是缩进多，而是多个路径引入同一抽象包（如 psr/log）且版本不兼容。这时 composer show -t 会显示它从 3–5 个不同位置进来，但终端宽度不够时缩进错位，你根本看不出哪条路径带了 ^2.0、哪条带了 ^1.0。
- 别靠肉眼数空格：用
composer show -t . | less -S固定列宽查看 - 查冲突源头：用
composer show --who psr/log看谁直接 require 它；加--no-dev过滤掉开发依赖干扰 - 注意虚拟包陷阱：结果为空？可能是通过
psr/log-implementation提供的，得回composer show -t全局扫provide字段
真正要盯紧的，从来不是缩进层数，而是同一抽象包在不同路径上声明的版本范围是否互斥——那个最小不可满足子集（MUS），往往藏在第三、第四层缩进之后，而且只在报错时才浮出水面。
