composer why symfony/console 只显示 laravel 是因该命令仅查直接声明依赖，而 illuminate/console 对 symfony/console 的约束被封装在 laravel/framework 内部，不暴露于项目 require 树；真正锁定版本的是 laravel/framework 本身，它是不可绕过的锚点。
composer why symfony/console 为什么只显示 Laravel，却不提 Illuminate？
因为 composer why 只查直接声明依赖，不追溯传递链。Laravel 的 composer.json 里明确写了 "symfony/console": "^6.4"，而 illuminate/console 是 Laravel 自己的包，它对 symfony/console 的约束被封装在内部，不会出现在你项目的 require 树里——composer why 看不到这层。
真正锁死版本的是 Laravel 框架本身，不是它的子包。运行 composer why symfony/console 输出的 laravel/framework 行，就是那个不可绕过的锚点。
- 如果输出里还出现
phpunit/phpunit或mockery/mockery，说明测试工具也在拉扯 Symfony 版本，尤其当它们还在用 ^5.x 时 -
composer show -t | grep "symfony/console"能看到真实锁定版本，比如(locked to 6.4.12)，这个值才是当前生效的 - 别信
composer.json里写的"^6.4"—— 它只是上限，实际装哪个由composer.lock决定
为什么 composer why illuminate/support 不返回任何结果？
因为 illuminate/support 是 Laravel 的内部组件，它从不被你的项目直接 require，也不在任何公开包的 require 字段里暴露。它被 laravel/framework 通过 replace 或 provide 声明“提供”，composer why 默认不穿透这类关系。
要查它怎么进来的，得加 --tree：composer why --tree laravel/framework，然后逐级展开看哪一层带出了 illuminate/support；或者直接 composer show -t | grep illuminate/support，确认它是否真被锁定了。
- 如果
composer why illuminate/support返回空，不代表它没被用——很可能它被laravel/framework的replace隐式替代了 - 遇到
(replaced by laravel/framework)这种标记，说明illuminate/support已被合并进框架主包，不再单独存在 - 想强制升级
illuminate/support？不行——它没有独立版本号，必须随laravel/framework一起升级
composer why-not symfony/console:^7.0 报错后该往哪翻？
报错最后一行通常是 laravel/framework 11.0.0 requires symfony/console (^6.4)，这就是你要改的地方。但别急着升级 Laravel——先确认你是否真的需要 Symfony 7，因为 Laravel 11 还没适配它，强行破锁会导致 illuminate/console 与 symfony/console 类签名不匹配。
更现实的做法是：检查 composer.json 里有没有其他包（比如私有 SDK 或 spatie/laravel-backup）悄悄 require 了旧版 Symfony，再用 composer prohibits symfony/console:^7.0 列出所有拦路虎。
-
composer why-not symfony/console:7.0.0必须写精确版本，^7.0会报Package not found - 如果输出里有
requires php ^8.2，而你用的是 PHP 8.1，那根本不用动依赖，先升 PHP - 看到
conflict with laravel/framework:>=11.0，说明目标版本和当前框架硬冲突，无解，只能等官方适配
composer show -t 里同一包出现两次，版本不同怎么办？
比如 symfony/console 在树里出现两次：一次是 laravel/framework → ^6.4，另一次是 phpunit/phpunit → ^5.4，Composer 最终选的是交集——也就是能同时满足两者的最高版本，通常是 6.4.x。但如果交集为空（比如一个要 ^5.4，另一个要 ^7.0），就直接失败。
这种双路径不是 bug，是 Composer 正常求解过程。关键看 (locked to X.Y.Z) 后面的版本号是否一致；如果不一致，说明依赖图里存在无法调和的约束分歧。
- 优先检查
require-dev里的包——phpunit、pestphp/pest、orchestra/testbench是高频冲突源 - 删掉
composer.lock后跑composer install --dry-run -v，看求解器卡在哪一行 - 不要手动改
composer.lock中的版本号——它会被下次 update 覆盖，且可能破坏依赖一致性
symfony/console 版本，Illuminate\Console\Command 可能立刻报 Class not found 或方法签名不兼容——这不是 Composer 能解决的，得看 Laravel 官方是否已发布对应适配补丁。
