答案是先用composer require --dry-run -v暴露SAT求解失败链，再查composer.lock中目标SDK的require字段及重复锁定版本，结合composer show --tree定位隐式冲突依赖。
升级第三方 SDK 时 Composer 报依赖冲突，本质不是“装不上”，而是当前 composer.json 约束与目标 SDK 的 composer.json 声明无法共存——必须逐层拆解约束来源，而不是反复 composer update。
看懂 composer require --dry-run -v 的真实报错
这是最直接暴露冲突根因的命令。它不会改任何文件，但会模拟安装并输出 SAT 求解失败的具体逻辑链。
- 错误里出现
because package-a requires package-b ^2.0 and package-c requires package-b ^1.5：说明两个 SDK 对同一底层包提出了互斥版本范围 - 报
can only install one of: package-d[3.0.0, ...], package-d[4.0.0, ...]：说明有间接依赖在拉取不同主版本，而 Composer 不允许并存 - 若含
requires php ^8.1 but your php version (8.0.30) does not satisfy that requirement：升级 SDK 同时抬高了 PHP 版本门槛，需先升级运行环境
检查 composer.lock 中已锁定的间接依赖版本
composer.lock 是当前解析结果的快照，但它的内容可能掩盖真实约束来源。直接打开该文件，搜索目标 SDK 名称（如 "monolog/monolog"），查看其 require 字段声明了哪些依赖及版本；再搜索这些依赖名，确认它们是否被其他包以不同版本重复要求。
- 重点关注
"version"字段是否为"dev-main"或"dev-develop"：这类不稳定版本常导致 SAT 求解失败 - 若发现同一包（如
symfony/event-dispatcher）在多个地方被锁为不同版本（如"5.4.21"和"6.3.0"），说明存在跨主版本依赖混用 - 不要手动编辑
composer.lock—— 它是自动生成的，修改后下次update会被覆盖
用 composer show --tree 定位“谁在拖后腿”
这个命令输出的是当前已安装依赖的完整树形结构，比 composer show 更能暴露隐式依赖路径。
- 执行
composer show --tree vendor/sdk-name查看目标 SDK 的全部上游依赖链 - 对比升级前后的树输出，重点找新增或变更的子依赖项（尤其是那些你没直接 require、但 SDK 内部 require 的包）
- 如果某子依赖（如
guzzlehttp/psr7）在树中出现了两次，且版本不一致（如1.9.1和2.6.2），这就是冲突源头
临时降级或排除冲突包做最小验证
当定位到具体冲突包（比如 phpunit/phpunit）时，可先绕过它验证 SDK 主体是否可用，避免陷入无限循环排查。
- 加
--ignore-platform-reqs仅跳过 PHP/扩展检查，不解决语义版本冲突 - 用
composer require vendor/sdk-name:version --no-update先写入composer.json，再手动删掉composer.lock和vendor/，最后composer update --with-all-dependencies强制全量重算 - 极端情况下，用
"replace": {"conflict-package": "*"}在composer.json中临时屏蔽某个引发冲突的包（仅限调试，不可提交）
真正难处理的从来不是报错信息本身，而是某个 SDK 的 composer.json 里写了 "php": ">=8.2"，而你的 composer.json 却只写了 "php": "^8.0" —— 这种约束层级错位，靠重试解决不了，必须人工对齐语义边界。
