依赖冲突本质是Composer无法满足所有版本约束，需用composer why-not定位阻断链、composer depends和show -t查依赖树、--with-dependencies定点更新，并以--dry-run -v预演验证。
依赖冲突不是包有问题，是 Composer 找不到一组能同时满足所有约束的版本组合 —— 解决它不靠删文件，靠看清谁在卡住谁。
composer why-not vendor/package:version 看清阻断链
这是最直接定位“为什么装不上”的命令。错误里说 Conclusion: don't install guzzlehttp/guzzle:^8.0？别猜，立刻跑：
composer why-not guzzlehttp/guzzle:^8.0
它会逐层列出：A 包要求 B 包，B 包又硬性锁死 guzzle
- 某个 dev 包写了
"conflict": {"guzzlehttp/guzzle": ">=8.0"}，哪怕你没直接 require 它，只要它被其他包拉进来就生效 - PHP 版本不匹配：目标包要求
php >=8.1，而config.platform.php或本地环境是 8.0 - 扩展缺失：包声明了
"ext-curl": "*"，但你的 CLI PHP 没开 curl 扩展
composer depends package/name 和 composer show -t 查依赖树源头
知道谁在拦路之后，得知道谁把它带进来的。比如 monolog/monolog 冲突了，先查谁依赖它：
立即学习“PHP免费学习笔记（深入）”；
composer depends monolog/monolog
输出可能是 laravel/framework v10.32.0 和 spatie/laravel-ignition v2.4.0 —— 这说明冲突来自这两个主依赖对 monolog 的不同胃口。再用：
composer show -t
看完整树形结构，重点找同一包出现多个版本分支的地方（比如 monolog 在树上既出现在 laravel 下面，又出现在 phpunit 下面），那就是冲突温床。注意：composer show -t 输出里如果某行缩进很深、版本号标红或带 (not installed)，往往是解析器已经放弃的那一支。
composer update vendor/package --with-dependencies 定点更新不扩圈
确认好要升级的包（比如 monolog/monolog）和它的兼容中间版（去 Packagist 查 v2.9.3 是否同时被上下游接受），执行：
composer update monolog/monolog --with-dependencies
关键在 --with-dependencies —— 它让 Composer 只重算该包及其**直接依赖**的版本，不会波及 phpunit、symfony/console 这类无关项。容易踩的坑：
- 写成
composer update "monolog/monolog:^3"：引号 +^会让 Composer 自己找“最新兼容版”，而不是你指定的 v3.0.0 - 漏掉
--with-dependencies：Composer 可能直接报错“无法满足要求”，因为它不敢动间接依赖 - 升级后不看
git diff composer.lock：确保只有预期的几行改动，如果连doctrine/inflector都变了，说明你没控住范围
composer update --dry-run -v 验证前先预演
任何 composer update 或 composer require 前，加 --dry-run -v 是底线操作：
composer update monolog/monolog --with-dependencies --dry-run -v
它不改任何文件，但会完整跑一遍 SAT 求解器，输出每一步尝试和失败原因。重点关注：
- 是否真找到了可行解（最后一行是不是
Resolving dependencies through SAT后跟成功提示） - 有没有出现
Skipped branch ... because of platform constraints—— 这说明platform配置或本地环境挡住了某些候选版本 - 解析过程中反复回溯某几个包（比如在
guzzlehttp/psr7和ralouphie/getallheaders之间来回跳），那大概率是它们的约束太紧，需要手动干预
真正麻烦的从来不是报错本身，而是错误信息里混着多层平台约束、conflict 规则、dev 分支稳定性设置 —— 这些东西叠加起来，会让 composer update 表面卡住，实际是在无限回溯。盯住 --dry-run -v 的输出，比盲目删 composer.lock 有用十倍。
