Composer通过SAT求解器解析依赖，当多包依赖同一库不同版本时可能冲突，需调整版本约束或更换组件以解决。
当使用 Composer 安装或更新 PHP 依赖时，如果多个包要求同一个依赖但版本不一致，就会出现版本冲突。Composer 会尝试自动解决这些冲突，但如果无法找到兼容的版本组合，就会报错。以下是 Composer 如何处理多版本冲突以及你可以采取的应对方法。
Composer 的依赖解析机制
Composer 使用一个称为 SAT 求解器（布尔可满足性求解器）的算法来分析所有包的依赖关系，并尝试找出一组能满足所有约束的版本。
它会：
- 收集项目根目录和所有已安装包的 composer.json 中的依赖声明
- 根据版本约束（如 ^1.2, ~2.0, 2.5.* 等）计算出每个包可接受的版本范围
- 尝试找出一个全局唯一的版本分配方案，使得所有依赖都能被满足
如果找不到这样的组合，就会抛出类似 “Conflicting requirements” 或 “your requirements could not be resolved” 的错误。
常见冲突场景与解决方案
以下是一些典型的版本冲突情况及应对方式：
1. 两个包依赖同一库的不同主版本
例如：包 A 需要 monolog/monolog:^1.0，包 B 需要 monolog/monolog:^2.0。
由于主版本不同，API 可能不兼容，Composer 无法同时安装两个版本（PHP 不支持并行加载同名包）。
你可以：
- 查看是否有新版的包 A 支持 monolog 2.0
- 寻找替代包替换掉不兼容的那个
- 联系包维护者推动兼容性更新
2. 版本约束太严格导致无交集
比如一个包要求 guzzlehttp/guzzle:7.2.0，另一个要求 ^7.4.0，两者无交集。
解决方法：
- 检查是否可以通过升级某些包来放宽约束
- 运行 composer update vendor/package 尝试局部更新
- 使用 composer why-not package/version 查看为何某个版本无法安装
3. 根项目锁定了旧版本
你在 composer.json 中手动指定了某个依赖的旧版本，而新引入的包需要更高版本。
建议：
- 修改根项目的版本约束以允许更高版本（如从 1.0 改为 ^1.0 或 ^2.0）
- 确认当前锁定版本是否真的必要
实用调试命令
遇到冲突时，这些命令能帮你定位问题：
- composer depends package/name：查看哪个包引用了该依赖
- composer prohibits package/name:version：查看为何某个版本不能安装
- composer update –dry-run：预演更新过程，不实际更改
- 查看 composer.lock 文件中的依赖树结构
基本上就这些。Composer 不支持为同一包安装多个版本，所以最终必须达成一个统一版本共识。关键是理清依赖链，调整约束或更换组件，让整个依赖图变得可满足。