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），或该版本根本没发布。
别删 vendor 和 composer.lock，先看 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。真正生效的是：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
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 的真实输出校验，不是配置没生效。
- Linux/macOS 直接调用目标二进制：
/usr/bin/php8.1 composer install - Windows 用完整路径：
"C:\php\php81\php.exe" composer install -
config platform.php只在生成部署包或 CI 中提前锁定目标环境时才用；本地开发机上设成"8.2"却用 PHP 7.4 运行，代码里一出现match就直接ParseError - 改了
platform.php必须跟composer update --lock，否则composer.lock还记着旧版本包
冲突根源往往不在缓存，而在环境不一致或约束未对齐。删了再装，只是用当前 php -v 重跑一遍解析逻辑——如果版本还是错的，报错会原样重现。
