Composer依赖树扁平化是为了通过SAT求解器为同名包选取满足全部约束的唯一最高兼容版本，解决菱形依赖冲突；实际vendor/目录为一级结构，show --tree仅为逻辑视图。
Composer 的依赖树扁平化不是为了简化目录结构，而是为了解决间接依赖带来的版本冲突问题——它强制所有同名包共用一个满足全部约束的版本，从而让 SAT 求解器能在全局范围内找交集。PHP 版本兼容性问题常藏在间接依赖里，比如你没直接 require symfony/console，但 laravel/framework 和 phpunit/phpunit 分别拉入了 ^6.4 和 ^7.0，而你的 PHP 8.0 环境只支持 Symfony 6.x，这时冲突就暴露了。
看懂扁平化结果：vendor/ 是真相，show --tree 是逻辑视图
实际安装后，vendor/ 下永远只有 guzzlehttp/guzzle、monolog/monolog 这类一级目录，绝不会出现 laravel/framework/vendor/symfony/console 这样的嵌套路径。这意味着：
- composer show -t（或旧版 show --tree）显示的是 Composer 解析出的逻辑依赖链，不是文件结构；它能帮你看到 谁在哪个层级引入了哪个版本
- 如果同一包在树中多次出现且版本不同（如 symfony/console 一次是 ^6.2，另一次是 ^7.0），说明这里存在潜在冲突点
- 真正生效的版本以 composer.lock 和 vendor/ 中实际存在的为准，不是 composer.json 里写的“理想值”
定位 PHP 兼容性卡点：从 why-not 到 depends 顺藤摸瓜
当你因 PHP 版本不匹配报错（例如 “symfony/console v7 requires PHP >=8.1”），不要只盯着根依赖。关键步骤是：
- 运行 composer why-not symfony/console:^7.0 —— 它会列出所有阻止该版本的约束，最后一行是你自己的 composer.json，往上每行都是间接来源（如 larastan/larastan v2.9 requires php ^8.1）
- 再执行 composer depends -r symfony/console，找出谁在“强制锁住旧版”，比如发现 myapp/utils 要求 ^6.2，那升级 myapp/utils 就可能释放限制
- 注意 require-dev 包全程参与解析，用 composer update --no-dev --dry-run -v 可快速验证是否是 dev 工具引发的 PHP 版本误判
精准干预：避免全量重算，用 --with-dependencies 定点升级
盲目删 composer.lock 或运行 composer update 容易放大问题。更稳妥的做法是：
立即学习“PHP免费学习笔记（深入）”；
- 若目标是升级 guzzlehttp/guzzle 以适配 PHP 8.2，先查可用版本：composer show guzzlehttp/guzzle，确认 ^7.8 或 ^8.0 是否已发布并支持
- 执行 composer update guzzlehttp/guzzle --with-dependencies —— 它只重算该包及其直接依赖，不会牵连 phpunit 或 sebastian/exporter
- 升级后立刻检查 git diff composer.lock，确保只有预期变更；若仍失败，说明某个子依赖本身有 PHP 版本硬限制，需单独处理（如降级该子依赖或换替代包）
绕过与隔离：replace、conflict 与 --no-dev 的适用边界
有些兼容性问题并非真冲突，而是约束写得太死。谨慎使用以下方式：
- 若确认两个包实际都兼容 symfony/console 6.4，但在 composer.json 中一个写 ^6.0、另一个写 ^6.2 导致求解器不敢选，可在 replace 字段声明："symfony/console": "self.version"
- 明确排除已知不可用组合：在 conflict 中加 "old/package": "3.1.0"，防止误装
- 生产部署时用 composer install --no-dev 隔离开发期工具包，它们常是 PHP 版本冲突的源头（如 phpstan/phpstan 要求 PHP 8.1+，而主业务只需 7.4）
