答案是composer why-not为第一反应命令——它逆推阻塞链，从根项目逐层向上定位谁在封杀目标版本，输出倒序，末尾“(required by...)”即阻塞源；空输出需查版本是否存在、require-dev或conflict声明。
版本冲突报错不是 Composer 出错了，是它明确告诉你：当前所有约束条件无法同时满足——没有一个版本能同时被所有依赖接受。
composer why-not 是第一反应命令
报错里出现 don’t install vendor/package:version（比如 don’t install guzzlehttp/guzzle:^8.0），立刻执行对应命令：
-
composer why-not guzzlehttp/guzzle:^8.0输出是倒序链路，从最后一行（你的根项目）往上读，每一行末尾的(required by ...)就是上一级阻塞源 - 如果输出为空，不是没冲突，而是版本号写错、未发布，或冲突来自
require-dev—— 它不会出现在根声明里，但会锁死依赖 - 看到
conflict with vendor/package >=2.0？说明那个包自己写了"conflict": {"vendor/package": ">=2.0"}，不是你配错了，是它封杀了
改 composer.json 比用 require 更可靠
composer require vendor/package:1.2.3 本质是“添加新依赖”，触发全局 SAT 求解，失败就回滚；真正稳住版本的做法是绕过求解，走强制覆盖路径：
- 手动编辑
composer.json，在require里写死具体版本："monolog/monolog": "2.9.3"（不带^或~） - 立即运行
composer update monolog/monolog --with-dependencies，强制连同直系子依赖一起重算 - 别用
composer update "monolog/monolog:^2"—— 引号 +^会让 Composer 自行选最新兼容版，可能跳到你没测过的2.10.0 - 执行后马上
git diff composer.lock，确认只有目标包及其直系依赖变动，没波及其他
别忽略 require-dev 和 platform 配置
很多冲突其实藏在开发依赖或 PHP 版本声明里，表面看不出来：
-
require-dev里的phpunit/phpunit可能拖着老版sebastian/exporter，间接锁死symfony/console；临时注释掉整个require-dev区块再试composer update，能快速验证 -
composer config platform.php "8.2.0"只影响依赖解析，不改变运行时；本地 PHP 是 7.4 却设成 8.2，Laravel 11 的match表达式一跑就ParseError -
config.platform.php必须配合composer update --lock才生效，否则composer.lock还记着旧平台下的包版本 - CI 脚本中务必前置
php -v打日志，确认实际调用的是哪个 PHP 二进制，避免which php和composer config platform.php不一致
最常被跳过的动作是盯住 git diff composer.lock —— 升级后第一眼要看的不是是否成功，而是哪些非目标包被连带改动了；那些没动过的旧版本，往往就是下一次冲突的伏笔。
