Composer版本冲突本质是多包对同一依赖提出互斥版本约束，导致无法选出满足所有要求的安装方案；典型表现为update卡住或“Conclusion: don't install”错误，需用composer why-not定位冲突源，并区分改依赖或换包策略解决。
Composer 版本冲突不是版本号不一致那么简单，本质是 composer.json 里多个包对同一依赖（比如 monolog/monolog）提出了互斥的版本约束，导致 Composer 无法选出一个满足所有要求的安装方案。
为什么 composer update 卡住或报 Conclusion: don't install 错误
这是最典型的冲突信号。Composer 在尝试解析依赖图时发现：A 包要求 "psr/log": "^1.0"，B 包却硬性指定 "psr/log": "^3.0"，而这两个范围没有交集。它不会自动降级或升级某个包去“凑合”，而是直接放弃。
常见诱因包括：
- 项目长期未更新，老项目里用了已废弃的包（如
guzzlehttp/guzzle6.x），而新引入的包只支持 7.x+ - 手动修改了
composer.json中的版本号（比如写成"^2.0.0"），但没验证是否与其他依赖兼容 - 某些包在
require-dev里声明了高版本工具（如phpunit/phpunit10），却和主依赖里的symfony/console5.x 冲突
用 composer why-not 定位具体冲突点
别猜，直接问 Composer 谁在挡路。假设你想装 laravel/sanctum 但失败，先运行：
composer why-not laravel/sanctum ^3.0
它会输出类似：
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5) laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
这就明确了冲突源头。再顺藤摸瓜查谁在锁死 guzzlehttp/guzzle：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer why guzzlehttp/guzzle
结果可能显示是某个老旧的 SDK 或自定义包在 require 它的 6.x 分支。
解决策略要分清「改依赖」还是「换包」
不是所有冲突都靠 composer update xxx 能解。得看谁更难妥协：
- 如果冲突来自你控制的私有包（比如
acme/payment-sdk），优先升级它的composer.json，放宽对底层库的约束，例如把"monolog/monolog": "1.26.1"改成"monolog/monolog": "^1.26 || ^2.0" - 如果冲突来自第三方包且它已停止维护（比如
aws/aws-sdk-php2.x），不要强行加--with-all-dependencies，而是找替代方案（aws/aws-sdk-php3.x 或async-aws/core） - 临时绕过（仅调试）可用
composer update --dry-run --verbose看完整决策路径，但别提交--ignore-platform-reqs到生产环境
PHP 版本不匹配也会伪装成依赖冲突
Composer 报 Root composer.json requires php ^8.1 but your php version (7.4.33) does not satisfy that requirement，看起来像依赖问题，其实是环境错位。此时 composer why-not 无效。
检查三处：
-
composer.json顶层"config": {"platform": {"php": "8.1.0"}}—— 这是模拟环境，删掉或改对 - 系统实际 PHP 版本：
php -v，确认 CLI 和 Web Server 用的是同一个 - Docker 或 CI 配置里是否硬编码了旧 PHP 镜像（如
php:7.4-cli）
很多团队卡在这一步，以为在调依赖，其实只是没切对 PHP 环境。
真正麻烦的从来不是报错信息本身，而是冲突链里夹着一个你不敢动、文档全丢、作者失联的私有包——这时候别硬刚版本号，先把它隔离到独立服务里更实在。
