Composer跨库依赖冲突本质是约束无数学交集，需用composer why-not定位阻断包，定点升级须加--with-dependencies，验证新包用--dry-run，版本选择应查Packagist真实交集，composer.lock比composer.json更反映实际版本。
Composer 跨库依赖冲突不是版本没对上，而是约束之间没有数学交集——删 vendor 或 composer.lock 不解决它，只会让下次报错更难定位。
用 composer why-not 定位谁在联合封杀目标版本
错误里写的 Conclusion: don't install laravel/framework:^11.0 是结果，不是原因。真正要查的是“谁在阻止它”。
- 运行
composer why-not laravel/framework:^11.0，输出会逐行列出所有阻断该版本的已安装包及其require约束，比如myapp/utils:2.4要求symfony/console:^5.4，而 Laravel 11 要求symfony/console:^7.0 - 特别注意输出中是否含
require-dev包（如orchestra/testbench、phpunit/phpunit）——它们常悄悄拉低主依赖版本，却容易被忽略 - 如果输出为空，说明不是依赖链问题，而是 PHP 版本、扩展缺失或
"config": {"platform": {...}}配置与当前环境不一致
执行 composer update vendor/package --with-dependencies 定点升级
盲目 composer update 会触发全量重算，SAT 求解器可能卡住；只写 composer update monolog/monolog 几乎总是失败，因为默认不升级它的子依赖。
- 必须加
--with-dependencies：它让 Composer 同时考虑并更新目标包所需的最小依赖集，而不是只动它自己 - 禁止带引号和模糊符号，比如
composer update "monolog/monolog:^3"——这会让 Composer 去找“兼容的最新版”，反而扩大搜索空间，加剧解析卡顿 - 想验证能否引入新包？先用
composer require vendor/package:version --dry-run，避免污染本地composer.lock
改 composer.json 版本约束前，先去 Packagist 找真实交集版本
把 "monolog/monolog": "^1.25" 改成 "^1.25 || ^2.10" 不是万能解法，它只在你的代码真能同时适配两套 API 时才成立。
- 打开
packagist.org，查目标包的发布历史，找一个被多个上游同时接受的中间版本，例如monolog/monolog v2.9.3同时满足 A 的^2.0和 B 的>=2.8.0 - 锁定它：
"monolog/monolog": "2.9.3"，再执行composer update monolog/monolog --with-dependencies - 若必须兼容两个大版本，确认所有调用点都做了运行时判断（如
class_exists('Monolog\Logger')），否则||写法只是把报错从安装阶段推迟到Class not found
composer.lock 里的实际版本比 composer.json 更真实
别只盯着 composer.json 里写的约束，composer.lock 才记录了当前环境中真正生效的版本组合，包括所有间接依赖的实际版本。
- 升级后立刻
git diff composer.lock，确认只有预期的包和其直系依赖被改动 - 团队协作时，
composer.lock必须提交，否则不同人本地composer install可能装出完全不同的依赖树 - 如果某次
composer update后行为异常，优先对比composer.lock差异，而不是怀疑代码逻辑
