Composer依赖冲突源于多包对同一依赖提出互斥版本要求，解决需定位冲突点（why-not）、查清依赖树（show -t）、合理使用--with-dependencies参数，并谨慎用replace/conflict干预。
Composer依赖版本冲突本质是多个包对同一依赖提出了互斥的版本要求，解决关键在于看清冲突源头、理解约束逻辑、再精准干预。
用 composer why-not 定位具体冲突点
当安装或更新失败时，错误信息往往只显示“无法解析依赖”，但没说清谁在阻止。直接运行：
composer why-not vendor/package:1.2.0它会列出所有已安装包中，哪些版本的包显式或隐式要求了与目标版本冲突的依赖范围。比如输出可能显示：
laravel/framework v10.30.0 requires symfony/console ^6.2
myapp/utils v2.1 requires symfony/console ^5.4
这就清晰指出：Laravel 10 和 utils v2.1 对 symfony/console 的要求无法共存。
检查 composer show 查清当前真实依赖树
运行：
composer show -t查看完整依赖树，特别注意同名包是否出现多个版本（Composer 通常只保留一个，但树中若显示不同路径引用不同版本，说明存在隐式冲突前兆）。重点观察：
- 冲突包是否被某个 dev-only 包（如 phpunit 或 phpcs）拉入，而主应用并不需要它出现在生产环境
- 是否有包通过 replace 或 provide 声明“假装”自己是某依赖，干扰解析
- 你自己的 composer.json 中是否写了过于宽松（如 *）或过于陈旧（如 ^1.0）的约束
合理使用 require --with-all-dependencies 或 update --with-dependencies
当想升级某个包却因依赖锁死失败，不要只跑 composer update vendor/pkg。它默认不更新该包的子依赖，容易卡住。改用：
composer update vendor/pkg --with-dependencies
这会让 Composer 同时考虑并更新其直接依赖，提高兼容成功率。类似地，首次添加一个新包时，如果它和现有生态有潜在冲突，加 --with-all-dependencies 可强制重算整个图，有时比默认行为更干净。
临时绕过冲突：用 replace 或 conflict 显式声明
某些场景下，你知道冲突是误报（比如两个包都兼容 symfony/console 6.x，但一个写死了 ^6.0，另一个写 ^6.2，实际无问题），可手动干预：
- 在 composer.json 的 replace 字段中声明："symfony/console": "self.version"，告诉 Composer “我自行保证这个包的行为一致”
- 若确定某版本组合绝对不可用，在 conflict 中明确排除："vendor/broken-pkg": "2.5.0"
- 慎用 --ignore-platform-reqs：它跳过 PHP/扩展版本检查，不是解决依赖逻辑冲突的正解，仅用于调试环境临时验证
不复杂但容易忽略
