Composer依赖冲突需从composer why-not输出倒推定位阻断链，重点看最后一行根依赖和conflicts行，结合--with-dependencies协调子依赖，避免盲目删lock文件。
Composer 跨框架依赖冲突没有银弹，核心是让冲突显性化、可追溯、可干预——不是删 lock 文件硬重装，而是看清谁在拦路、为什么拦、怎么绕开或说服它让路。
composer why-not 输出怎么看？从最后一行倒着读
错误提示里只写 “can’t install laravel/framework v10.32.0”，但没说谁不让装。这时运行 composer why-not laravel/framework:10.32.0，输出是一条反向依赖链，每行末尾的 (required by ...) 是上一级依赖，最后一行才是你的 composer.json 根声明（即你主动写的 require）。常见误读是看到中间某行写 conflict with symfony/console (>=6.0) 就去查 symfony/console，其实那是它自己声明的 conflict 规则，真正卡住的是它上面那个包对 symfony/console 的版本要求和另一个包冲突了。
关键点：
- 先确认目标版本是否真被需要：比如你根本没在
composer.json里写laravel/framework，却报这个错，大概率是某个 dev 包（如orchestra/testbench）拉进来的 - 注意
require-dev包全程参与解析，哪怕你只跑composer update不带参数，phpunit/phpunit的约束也可能把symfony/console卡死在 5.x - 如果某行显示
package-x v2.1 → requires symfony/console ^5.4，另一行是laravel/framework v10.32.0 → requires symfony/console ^6.4，那冲突点就是symfony/console，不是 Laravel 本身
composer update --with-dependencies 不是“升级”，是“连带协调”
盲目执行 composer update vendor/package 很容易失败，因为默认行为只更新该包本身，不碰它的子依赖。而实际冲突往往藏在子依赖里。比如你想升 guzzlehttp/guzzle 到 ^8.0，但它依赖的 psr/http-client 被另一个包锁死在 1.0，这时只升 guzzle 没用。
正确做法是加 --with-dependencies：
-
composer update guzzlehttp/guzzle --with-dependencies：让 Composer 同时考虑并更新guzzlehttp/guzzle的直接依赖（如psr/http-client、ralouphie/getallheaders），提高兼容成功率 -
composer require new/package --with-all-dependencies：首次引入新包时，强制重算整棵树，适合你信任该包且愿意接受关联变更的场景 - 别用
composer update全量重算——SAT 求解器可能卡住 5 分钟以上，尤其在复杂项目中
版本约束写法差异直接影响能否找到交集
^1.2.3 和 ~1.2.3 看似差不多，但对求解器来说差一个维度：
-
^1.2.3等价于>=1.2.3 ，允许小版本和补丁升级 -
~1.2.3等价于>=1.2.3 ，只允许补丁升级
所以如果 A 包写 "monolog/monolog": "^1.25"，B 包写 "monolog/monolog": "~2.9.0"，它们根本无交集——~2.9.0 最多到 2.9.9，而 ^1.25 死守 1.x。这时就得去 Packagist 查 monolog/monolog 的发布记录，找一个能同时被双方接受的版本，比如 2.9.3 同时满足 ^2.0 和 >=2.8.0，然后手动锁死："monolog/monolog": "2.9.3"。
其他常见陷阱：
- 写
*或>=1.0太宽泛，容易拉进不兼容的主版本 - 信不过语义化版本的包，就别用
^2.0，改用"2.10.2"这种明确版本号 - 私有包或 fork 项目若用了
replace，必须确保被替代项真能被完全覆盖，否则运行时报 Class not found
composer.lock 是证据，不是病灶
团队协作中拉新代码后报 “Root requires X but Y is installed”，大概率是别人提交了新的 composer.json 但没连带提交 composer.lock。此时不要急着删 vendor/ 或 composer.lock，它们是问题的证据，不是病灶。
标准动作是：
- 先
git checkout -- composer.lock恢复 lock 文件，再composer install——它严格按 lock 装，通常就能过 - 如果确定要升级，用
composer update vendor/package-name精准更新单个包，避免全量重算导致其他包意外降级 - 执行
composer install --dry-run预演安装路径，看哪条链断了，比盲猜高效得多
最易被忽略的一点：冲突常来自 require-dev 中的测试工具链，比如 phpunit/phpunit 和 pestphp/pest 对 symfony/console 的要求打架，但你生产环境根本不需要它们——这种时候该做的是移出 require-dev，而不是强行协调。
