Composer依赖冲突是穷举无解后的明确拒绝，应先用composer why-not定位阻断链、查composer.lock实际版本，而非删锁文件；重点分析报错中“Problem 1”的依赖链及requires行，结合composer show --tree和--dry-run -v精准识别隐藏冲突源。
Composer 依赖冲突不是“装不上”，而是它已穷举所有组合后确认无解——别删 composer.lock，先让报错自己说话。
看懂 “Problem 1” 里谁在打架
报错开头的 Problem 1 不是装饰，它按逻辑顺序列出冲突链：最上面是你想装/更新的目标（比如 laravel/sanctum:^3.0），往下是它依赖的包（如 guzzlehttp/guzzle:^7.2），再往下就是和它冲突的“老对手”（如 myapp/sdk:v2.4 要求 guzzlehttp/guzzle:^6.5）。
重点盯住带 requires 的行，尤其是同一包名反复出现且版本无交集的地方：
-
^6.5和^7.2没交集 -
~2.4.0和^3.0互斥 - PHP 版本约束被忽略（如顶层写了
"php": "^8.1"，但某个依赖只支持 7.4）
用 composer why-not 验证真实阻止源
假设报错说装不了 monolog/monolog:2.9.0，立刻运行：
立即学习“PHP免费学习笔记（深入）”；
composer why-not monolog/monolog:2.9.0
它会输出类似：
myapp/core dev-main requires monolog/monolog (^1.25) laravel/framework v10.30.0 requires monolog/monolog (^2.0)
这就确认了冲突不是缓存或拼写错误，而是两个已声明依赖对同一包提出了无法共存的要求。
注意：composer why-not 只分析“已被声明但无法满足”的包，必须带完整包名+版本号（如 vendor/package:1.2.3 或 vendor/package:^2.0）；若返回 Package not found，说明该版本根本没在你的依赖图里注册过。
查清依赖树，揪出隐藏拉入者
有些冲突不显现在 Problem 1，而是藏在深层依赖里，比如某个 require-dev 包悄悄拉进了一个不兼容的 symfony/console。运行：
composer show --tree | grep "symfony/console"
能直接看到它被谁引入、路径多深、是否带 (locked to 5.4.32)——后者意味着这个版本已在 composer.lock 固定，不删 lock 或不用 --with-all-dependencies 就没法松动。
更细粒度地验证版本选择逻辑，可用：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"
特别注意 require-dev 中的包（如 phpunit/phpunit）也参与统一解析，它们常带高 PHP 版本或扩展要求，却容易被忽略。
执行 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 查。
真正难处理的不是报错本身，而是那些被 require-dev 拉进来的间接依赖，以及 composer.lock 里早已固定却没人记得为何固定的版本——它们不会出现在你写的 composer.json 里，但会默默封死所有升级路径。
