composer why-not 能立刻定位阻断链：输出从下往上读，末尾“(required by …)”指明卡点，如 spatie/laravel-backup v7.2.0 requires symfony/console ^5.4；输出为空则多因版本号错误或未发布；配合 composer show --tree 查真实依赖快照，精准更新需加 --with-dependencies。
composer why-not 能立刻定位谁在拦路
报错里那句 Conclusion: don't install laravel/framework:v11.0.0 不是警告，是数学结论：当前约束下无解。但错误本身不告诉你谁卡住了。直接跑 composer why-not laravel/framework:v11.0.0，它会倒推依赖链，每行末尾的 (required by ...) 就是向上追溯的起点。
真正卡死的包往往藏在中间层，比如：spatie/laravel-backup:v7.2.0 requires symfony/console ^5.4——这时候你就知道该去推这个插件升级，而不是硬改 Laravel 版本。
- 输出为空？大概率是版本号写错了（比如写了
^11.0而不是laravel/framework:11.0.0），或该版本根本没发布 - 如果某行末尾是
(required by root)，说明是你自己composer.json里写的约束直接冲突了
composer show --tree 是真实快照，不是理想状态
composer show --tree 显示的是当前 composer.lock 和 vendor/ 的真实快照，不是你 composer.json 里写的“应该有”。很多冲突就藏在第二、三层依赖里：
- 运行
composer show --tree | grep "symfony/console"，能看到它被谁引入、路径多深、是否标了(locked to 5.4.32) - 如果同一包被多个路径引入不同版本（比如
symfony/console同时出现在laravel/framework和phpunit/phpunit下），这就是典型间接冲突源 - 看到
(replaced)或(provided)标记，得立刻去对应包的composer.json查replace字段，确认是否真能等价替代
升级单个包必须加 --with-dependencies
composer update monolog/monolog 默认拒绝更新它的子依赖，常直接报 Your requirements could not be resolved。真正生效的是：
-
composer update monolog/monolog --with-dependencies：只重算该包及其直系依赖，不影响其他包 -
composer require symfony/console:^5.4 --no-update：先改composer.json，再手动composer update symfony/console，把影响控制在最小范围 - 避免写
composer update "monolog/monolog:^3"——引号 + 波浪号会让 Composer 尝试找兼容最新版，而非你想要的精确版本
升级后立刻 git diff composer.lock，确认只有预期包和其子依赖被改动。
PHP 版本不匹配不是“忽略就行”的问题
报错 requires php ^8.1 but your PHP version (7.4.33) does not satisfy that requirement 是 Composer 在用 php -v 的真实输出校验，不是配置项可绕过。它发生在解析早期，甚至早于依赖图构建。
常见误操作是加 --ignore-platform-reqs 强行通过，但这只是掩盖问题——实际运行时仍可能因函数不存在、语法报错而崩溃。
正确做法是：
- 先确认本地 PHP 版本：
php -v - 检查目标包的
composer.json中require.php字段（例如"php": "^8.1"） - 要么升级 PHP，要么降级该包到兼容版本（用
composer require vendor/package:~2.0这类约束）
最易被忽略的一点：某些包在 require-dev 里声明了高版本 PHP，但你在生产环境执行 composer install --no-dev 时仍会校验——因为 Composer 默认仍读取整个 composer.json 的 platform 配置。
