Composer依赖冲突本质是无版本组合能满足所有约束，应优先用composer prohibits定位阻断链（why-not为空时）、composer show --tree查真实依赖树、--dry-run -v看求解过程Because链，而非盲目删文件。
Composer 依赖冲突不是“装不上”，而是它明确告诉你：没有一组版本能同时满足所有约束——检测的关键，是让 Composer 把阻断链摊开给你看，而不是靠删文件或猜。
composer why-not 输出为空？试试 composer prohibits
报错里写 Conclusion: don't install laravel/framework:^11.0，但 composer why-not laravel/framework:^11.0 返回空？说明这个包根本没在你的 composer.json 里声明过，why-not 查不到源头。
这时必须换 composer prohibits，它从目标包出发反向翻出所有拦路的依赖：
- 命令必须带完整版本号，例如
composer prohibits laravel/framework:11.0.0（不能写^11.0） - 输出每行末尾的
(for spatie/laravel-backup v7.2.0)就是真正卡死你的包 - 如果某行显示
symfony/console ^5.4和laravel/framework:11.0.0要求的^6.4对撞，那冲突点就在这里，不是 Laravel 本身
composer show --tree 是真实现场，不是理想模型
composer show --tree 展示的是当前 composer.lock 已成功解析出的依赖结构——它反映的是你此刻 vendor 里真正在跑的东西，不是你“以为”的依赖关系。
常见误判场景：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 主应用没 require
guzzlehttp/guzzle，但phpunit/phpunit在require-dev里拉进了^6.5，树里就会出现guzzlehttp/guzzle 6.5.5，且被标记为(required by phpunit/phpunit 9.6.10) - 同名包出现在不同路径下（比如
monolog/monolog同时被laravel/framework和spatie/laravel-ignition引入），但 Composer 只保留一个版本——树里若显示两个路径指向不同版本，说明已有隐式冲突前兆 - 某个私有 SDK 的
composer.json里写了"conflict": {"ext-json": "，而你 PHP 是 8.2，<code>show --tree不会报错，但composer install会失败
composer update 不生效？别忘了 --with-dependencies
改完 composer.json 里的 "guzzlehttp/guzzle": "^7.2"，执行 composer update guzzlehttp/guzzle 却没变化？因为默认只更新目标包本身，不碰它的子依赖。
真正起效的操作是：
- 加
--with-dependencies：它会让 Composer 重新计算整条依赖链，包括guzzlehttp/guzzle的psr/http-message、ralouphie/getallheaders等直接依赖 - 如果连带升级了
symfony/http-foundation从 v5 到 v6，注意Response::setContent()在 v6.4+ 已弃用，运行时可能崩 - 想只升补丁不跳主版本，确保
composer.json写的是"^7.2"，不是"*"或">=7.0"—— 后者会让 SAT 求解器找到一堆“合法但危险”的组合
--dry-run -v 是唯一能看清冲突在哪一行的方法
全量 composer update 容易卡住几分钟，还可能引入新问题。--dry-run -v 不改任何文件，但把整个求解过程摊开：
- 盯末尾几行的
Because链，比如Because package-a v2.1 requires monolog/monolog ^1.25, and package-b v3.0 requires monolog/monolog ^2.10—— 这就是无交集的铁证 - 看
Root requirements段落，确认哪条"vendor/name": "^x.y"是整场冲突的起点 - 注意
Found conflicting requirements下列出的具体包名和版本范围，它们才是你要动手调的对象 - 漏掉
-v参数，你只看到“无法解析”；有了它，才能看见“谁在拉扯谁”
最常被忽略的一点：conflict 字段是全局硬拦截，哪怕你项目里没 require Laravel 11，只要某个已装包偷偷把它拉进来，Composer 就会拒绝整个安装——查 composer show --tree 之前，先扫一眼所有已装包的 composer.json 里有没有 conflict 声明。
