Composer依赖树是扁平化的，因为它将所有包统一安装到vendor/一级目录，通过SAT求解器强制为同名包选取满足全部约束的唯一最高兼容版本，从而解决菱形依赖冲突；实际文件结构无嵌套，仅逻辑视图（如show --tree）呈现层级。
Composer 依赖树为什么是扁平化的
Composer 不保留原始嵌套结构，而是把所有依赖“拉平”到 vendor/ 目录一级，每个包只存一份——这是它解决菱形依赖冲突的前提。你看到的 composer show --tree 输出只是逻辑视图，实际安装结果永远是扁平目录结构。
这种设计不是为了省空间，而是为了让 SAT 求解器能统一约束：同一个包被 A 和 B 同时 require，就必须找一个版本同时满足 A 的 "guzzlehttp/guzzle": "^7.0" 和 B 的 "guzzlehttp/guzzle": "^6.5 || ^7.0"。一旦找不到交集，就会降级甚至报错。
如何验证当前项目的扁平化结果
直接看 vendor/ 目录最直观：里面只有包名目录（如 guzzlehttp/guzzle、monolog/monolog），没有嵌套的 “A → B → C” 子目录结构。但要注意：
-
composer show --tree显示的是解析后的逻辑依赖路径，不是文件系统结构 -
composer show --locked列出的是最终被锁死的唯一版本，对应vendor/中真实存在的那一份 - 若某个包在不同路径下 require 了不同子依赖（比如
guzzlehttp/guzzle的require字段里列了psr/http-clientv1 和 v2），那是它的“私有依赖视图”，不影响其他包引用该版本时加载哪个psr/http-client
扁平化带来的典型问题与应对
最常被误读的是：看到 composer.lock 里某个包只出现一次，就以为“没冲突”。其实冲突发生在解析阶段，lock 文件只是结果快照。
常见现象包括：
- 执行
composer update guzzlehttp/guzzle却没升级成功——可能被另一个包的约束卡在旧版 - 本地开发时用
path仓库引入包，结果它的autoload把你项目src/加进去了，造成“逻辑上依赖自己” - 运行
composer prohibits vendor/package:new-version才发现是laravel/framework的某子依赖在阻止
这时不要硬改 composer.json 的版本号，优先用 composer depends vendor/package 顺藤摸瓜，再结合 --dry-run -v 看求解器实际卡在哪条路径。
什么时候不能依赖扁平化机制
扁平化只对“同一包名 + 同一命名空间”有效。如果两个包名字不同但功能重叠（比如 monolog/monolog 和 symfony/debug 都提供日志能力），Composer 不会合并或干预——它们各自独立安装，也可能引发运行时冲突。
更隐蔽的是 autoload 冲突：两个包都通过 PSR-4 把 App\ 映射到不同路径，而你的代码又同时用了它们的类。这种问题不会在 composer install 阶段报错，但运行时会因类重复定义或找不到类而崩溃。
真正需要警惕的，从来不是“有没有扁平化”，而是“扁平之后，那些被隐藏的私有依赖视图和 autoload 边界，是否还清晰可控”。
