Composer版本冲突本质是依赖约束无交集，需用composer why-not定位阻断链路，结合--dry-run -v模拟求解、show查版本交集，精准调整版本而非删lock或全量update。
别删 composer.lock，也别直接 composer update 全量升级——90% 的冲突靠诊断命令就能定位到具体哪两个包在“打架”，以及谁在卡版本。
看懂报错末尾那句 “because A requires B ^2.0, but C requires B ^1.25”
Composer 报错时最后一段才是关键，它不会笼统说“冲突了”，而是明确写出矛盾双方：哪个包、提了什么版本要求、被谁挡住了。这比日志开头的堆栈有用得多。
- 重点抓重复出现的包名，比如
monolog/monolog、symfony/console、phpunit/phpunit——它们常是冲突枢纽 - 注意
^和~的语义差异：^2.0允许 2.x 所有版本，~2.0.0只允许 2.0.x，范围更窄，容易和别人不重叠 - 如果报错里带
require php ^8.0但你本地是 PHP 7.4，那就不是依赖问题，是环境不匹配，先改config.platform.php或升级 PHP
用 composer why-not 直接查“为什么这个版本装不上”
这是最常被跳过的命令，但它能精准指出阻断链路。必须带完整包名和版本号，例如 composer why-not monolog/monolog:^2.0，它会输出类似：
monolog/monolog 2.0.0 requires php ^7.2 || ^8.0 laravel/framework v9.52.0 requires monolog/monolog ^1.12
说明 Laravel 9 锁死了 monolog 的大版本，你没法升到 2.x。
- 如果返回
[InvalidArgumentException] Package not found，说明该包还没写进composer.json，先composer require vendor/name:version再试 - 想查谁在强制拉低某个包的版本？用
composer depends -r vendor/package，它会列出所有上游约束，带requires的那行才是真源头 - 不要对
dev-main或2.x-dev运行why-not，它只认已发布的稳定 tag
用 composer update --dry-run -v 模拟解析全过程
这个命令不改任何文件，但会完整走一遍 SAT 求解流程，输出每一步尝试和回退原因。关键信息在最后几行，它会告诉你“尝试了哪些组合，为什么都失败”。
- 加
-v是为了看到依赖图回溯路径，否则只给一句“无法解析” - 如果发现冲突来自
require-dev（比如barryvdh/laravel-debugbar），加--no-dev重试，能快速确认是不是开发依赖拖了后腿 - 输出里若出现同一包多个版本并存（如
symfony/console v5.4.33和v6.4.7），说明有包用了replace或conflict声明，得去对应包的composer.json查
锁定中间兼容版本比硬升硬降更稳
盲目把 "laravel/framework": "^10.0" 改成 "^9.50" 常失败，因为 Laravel 9 依赖的 symfony/* 范围更窄，可能和现有 symfony/http-kernel 冲突。不如找一个三方都接受的中间版。
- 先用
composer show vendor/package列出所有可用版本，再用composer show vendor/package 2.9.1看它具体 require 了哪些包及其版本范围 - 找到交集版本后，写死在
composer.json中，例如"monolog/monolog": "2.9.1"，然后只运行composer update monolog/monolog - 避免用
*或dev-master，这些会让 Composer 失去收敛依据；^1.2.0比~1.2更安全，前者允许补丁和次要更新，后者只允许补丁
真正麻烦的从来不是找不到解，而是没看清约束来源就动手改——composer.lock 里每个版本都是求解器算出来的结果，删了它等于让问题从“可复现”变成“不可控”。
