composer依赖冲突时会报错中断，如“root composer.json requires monolog/monolog ^2.0, but version 3.0.0 is installed”，需检查require/require-dev版本约束、调整语义化范围、慎用dev分支和platform配置，并用composer why/prohibits定位源头，删除composer.lock后重装。
依赖冲突时 composer install 报错的具体表现
运行 composer install 或 composer update 时，如果多个包对同一依赖（比如 monolog/monolog）要求不同版本范围，Composer 会直接中断并输出类似错误：
Root composer.json requires monolog/monolog ^2.0, but version 3.0.0 is installed.
这不是网络或权限问题，而是 Composer 的约束求解器明确判定：当前 lock 文件、已安装包、composer.json 中的版本声明三者无法同时满足。
修改 require 和 require-dev 的版本约束是第一操作
冲突根源几乎总在 require 或 require-dev 区块里写死了不兼容的版本。必须手动打开 composer.json 调整：
- 把硬编码的
"laravel/framework": "9.12.3"改成语义化范围，如"^9.12"或更宽松的"^9.0" - 若两个包分别要求
"guzzlehttp/guzzle": "^7.2"和"^8.0"，可尝试统一降级到"^7.5"（前提是业务代码不调用 v8 新 API） - 避免使用
dev-master或dev-main—— 它们没有稳定约束，极易引发不可预测的冲突
慎用 platform 配置伪造 PHP 或扩展版本
当报错提示 Your PHP version (8.2.1) does not satisfy the required version constraint，但你确认环境实际支持，可能是 Composer 错误读取了系统配置。这时可在 composer.json 加入：
"config": {
"platform": {
"php": "8.2.1",
"ext-zip": "1.0"
}
}
注意：platform 是“告诉 Composer 我有这些”，不是“让 Composer 忽略检查”。滥用会导致线上部署失败，因为真实环境未必真有该扩展。
冲突持续时，用 composer why 和 composer prohibits 定位源头
别靠猜。先运行 composer why monolog/monolog 查看哪些包间接依赖它；再执行 composer prohibits guzzlehttp/guzzle:8.0 看哪个包明确拒绝该版本。常见陷阱：
- 某个包在
require-dev里锁死旧版，但你在require里引入了新版 —— 这种跨区块冲突容易被忽略 -
composer.lock文件残留旧约束，改完composer.json后必须删掉 lock 文件再重装，否则 Composer 仍按旧规则解析 - 私有包的
composer.json没同步更新，本地开发时没察觉，CI 构建才暴露
依赖树不是线性结构，一个看似无关的包升级可能通过多层传递触发底层冲突。动手改之前，先看清谁在拉谁、谁在挡谁。
