Composer依赖冲突本质是约束无数学交集，需用composer why-not定位阻断包，检查require-dev、PHP版本及platform配置，update须带--with-dependencies，版本修改需有真实兼容依据。
Composer 环境依赖冲突不是“装不上”，而是约束之间没有数学交集——删 vendor 或 composer.lock 只会掩盖这个事实，不会改变它。
composer why-not 是唯一可信的起点
错误里写的 “Conclusion: don’t install laravel/framework:^11.0” 不是结论，只是结果。真正要问的是：谁在联合封杀它？
- 运行
composer why-not laravel/framework:^11.0，它会逐行列出所有阻断该版本的已安装包及其约束，比如：myapp/utilsv2.4 requiressymfony/console^5.4，而 Laravel 11 要求symfony/console^7.0 - 注意输出里是否含
require-dev包（如orchestra/testbench、phpunit/phpunit）——它们常悄悄拉低主依赖版本 - 如果输出为空，说明不是依赖链问题，而是 PHP 版本、扩展或
platform配置不匹配，此时应检查composer.json中的"config": {"platform": {...}}是否与当前环境一致
composer update 必须带 --with-dependencies 才有效
只写 composer update monolog/monolog 几乎总是失败。Composer 默认不升级它的子依赖，而冲突往往卡在子依赖上。
- 正确做法是：
composer update monolog/monolog --with-dependencies—— 这会让 Composer 同时考虑并更新monolog/monolog所需的最小依赖集 - 若想验证某个新包能否引入，先用
composer require vendor/package:version --dry-run，避免污染本地锁文件 - 切忌写
composer update "monolog/monolog:^3"：引号 +^会让 Composer 尝试找“兼容的最新版”，而非你意图的“精确范围”，反而扩大搜索空间，加剧解析卡顿
版本约束修改必须有交集依据
把 "monolog/monolog": "^1.25" 改成 "^1.25 || ^2.10" 不是万能解法，它只在你的代码真能同时适配两套 API 时才成立。
- 先去 Packagist 查目标包的发布历史，找一个被多个上游同时接受的版本，例如
monolog/monologv2.9.3 同时满足 A 的^2.0和 B 的>=2.8.0 - 然后锁定它：
"monolog/monolog": "2.9.3"，再执行composer update monolog/monolog - 如果必须兼容两个大版本，确认所有调用点都做了运行时判断（如
class_exists('Monolog\Logger')），否则||写法只是把报错从安装阶段推迟到Class not found
composer.lock 里的实际版本比 composer.json 更真实
别只盯着 composer.json 里写的约束，composer.lock 才是你项目此刻真实的依赖快照。
- 用
composer show monolog/monolog查看当前安装的版本和它的完整require列表，确认它是否被某个 dev-only 包间接拉入 - 运行
composer show --tree | grep monolog，观察是否出现多条路径指向不同版本（哪怕最终只保留一个，也说明存在隐式冲突前兆） - 如果发现冲突源来自
require-dev，且生产环境不需要，可考虑移除该包，或改用composer install --no-dev部署，避免测试工具污染主依赖树
最常被忽略的点：Composer 的 SAT 求解器在遇到 conflict、replace 或超过 30 个包时，复杂度会指数上升。一旦 composer update 卡在 Resolving dependencies 超过 5 分钟，基本可以确定是解析瓶颈，而不是网络或权限问题——这时该停下手头操作，回到 why-not 和 --dry-run -v 日志里找反复回退的包。
