composer 版本冲突源于依赖约束区间无交集，需用 composer why-not 定位冲突源，再通过收紧/放宽约束、--with-dependencies 精准更新或 --with-all-dependencies 重算依赖图解决。
Composer 版本冲突不是版本号“不一样”就报错，而是多个包对同一依赖提出的版本范围没有交集——只要 guzzlehttp/guzzle、monolog/monolog 这类共享依赖的约束区间不重叠，Composer 就会直接放弃解析，报 Conclusion: don't install 或卡在 Resolving dependencies。
用 composer why-not 定位谁在封杀目标版本
错误信息里只写“无法安装 vendor/package:2.5.0”，但没说谁拦着。运行：
composer why-not vendor/package:2.5.0
它会逐级列出所有已安装包中，哪些版本显式或隐式锁死了该包的可用范围。比如输出：
laravel/framework v10.30.0 requires symfony/console ^6.2<br>myapp/utils v2.1 requires symfony/console ^5.4
这就清楚表明：Laravel 10 和 utils v2.1 对 symfony/console 的要求根本没法共存。
- 别跳过这步直接删
composer.lock——你可能掩盖了真实依赖链 - 如果输出里出现
dev-main或dev-develop，检查是否漏配了"minimum-stability": "dev" - 注意
why-not不会显示被replace或conflict干预过的包，得额外查composer show -t
改 composer.json 版本约束前先确认交集是否存在
盲目把 "monolog/monolog": "^1.25" 改成 "^1.25 || ^2.10" 没用，除非你代码真能兼容两个主版本。更务实的做法是：
- 去 Packagist 查哪个小版本被上下游同时接受（比如
v2.9.3可能既满足 A 的^2.0，又满足 B 的~2.9） - 收紧过宽约束：把
"guzzlehttp/guzzle": "*"锁到已验证稳定的"7.8.1"，避免引入破坏性变更 - 放宽过严约束：把
"aws/aws-sdk-php": "3.240.0"改成"^3.240"，给 Composer 留出调整空间 - 改完立刻跑
composer update vendor/package --with-dependencies，而不是composer update全量重算
composer update --with-dependencies 是定点升级的关键
想升 monolog/monolog 到 3.0.0，但直接跑 composer update monolog/monolog 常失败——因为 Composer 默认不更新它的子依赖，而 monolog 3.0 可能要求 php >=8.1 或 psr/log ^3.0，这些旧版本还卡在 lock 文件里。
- 必须加
--with-dependencies：它会让 Composer 同时考虑并升级该包所需的最小依赖集 - 别写
composer update "monolog/monolog:^3"——引号 +^会让 Composer 自行找最新兼容版，不是你要的精确版本 - 如果提示 PHP 版本不匹配，先检查
composer.json里的config.platform.php是否和当前环境一致 - 升级后立刻
git diff composer.lock，确认只有monolog/monolog及其直系依赖变动
删 vendor 和 composer.lock 是最后手段，且要配合 --with-all-dependencies
当长期没更新依赖、或接手一个混乱项目时，缓存和锁文件可能已固化一堆隐性冲突。这时可以清场，但不能裸跑 composer install：
- 先
composer clear-cache清本地下载缓存 - 删掉
vendor/和composer.lock - 再执行
composer update --with-all-dependencies，让 Composer 从头推演整个依赖图 - 避免用
--ignore-platform-reqs提交到生产——它只是关掉校验，不解决实际兼容性 - 如果仍失败，说明存在硬性互斥（比如两个包都
provide同一接口但实现不兼容），只能换包或重构
真正难处理的从来不是“怎么升版本”，而是“哪个包在悄悄拖后腿”——composer why-not 和 composer show -t 看到的依赖树，往往比报错信息本身更接近真相。
