Composer依赖冲突本质是依赖图中版本约束无交集，需用composer prohibits定位源头，再通过降级/升级依赖或检查必要性解决，而非简单删lock文件。
Composer 安装包报错“version conflict”本质是依赖图中存在无法同时满足的约束条件，不是删掉 composer.lock 就能解决的。
为什么 composer require 会提示“found x versions, but x.x.x is not installable”
这是 Composer 在解析依赖树时发现：你要求的新包（比如 monolog/monolog:^3.0）和已有包（比如 laravel/framework:v10.48.0）共同依赖的某个底层包（如 psr/log），两者提出的版本范围没有交集。
-
laravel/framework v10.48.0要求psr/log ^2.0 || ^3.0 -
monolog/monolog ^3.0要求psr/log ^3.0—— 看似兼容，但若项目里已存在psr/log 2.0.0且被其他包硬锁定，Composer 就无法升级它 - 更隐蔽的是：某些包在
require-dev中声明了冲突版本，也会参与解析
用 composer prohibits 快速定位冲突源头
别靠猜。直接运行命令让 Composer 告诉你谁在拦路：
composer prohibits psr/log:3.0.0
输出类似：
myapp dev-main requires psr/log (^2.0) symfony/console v6.4.3 requires psr/log (^1.1 || ^2.0)
说明 psr/log:3.0.0 被这两个依赖明确拒绝。此时你要决定：
– 是降级新包（如改用 monolog/monolog:^2.10）
– 还是升级冲突依赖（如把 symfony/console 升到 v7+，它支持 psr/log ^3.0）
– 或者检查是否真需要该版本——有些包 v3 仅增加 PHP 8.2 支持，而你还在用 PHP 8.1
临时绕过冲突的三种操作边界
这些不是修复，是诊断或应急手段，用完必须回溯原因：
- 加
--with-all-dependencies：强制让 Composer 尝试升级所有间接依赖来腾出空间，适合小项目，但可能意外升级一堆包导致运行时异常 - 加
--ignore-platform-reqs：跳过 PHP 版本、扩展等检查，仅当确认环境实际满足却因配置误判时才用（比如ext-gd已启用但php.ini未正确加载） - 手动编辑
composer.json的conflict段，显式排除某个版本（如"conflict": {"psr/log": "3.0.0"}），再composer update—— 这等于告诉 Composer “我知道风险，别装这个”，慎用
长期避免冲突的关键动作
依赖冲突不是偶然，是项目演进中的信号：
- 定期运行
composer outdated --direct，只更新直连依赖，不碰树深处，降低爆炸半径 - 在
composer.json中为关键包（如框架、ORM）写死最小稳定版，例如"laravel/framework": "^10.0"而非"^10"，避免某天自动升到 v11 引爆全链 - CI 流程里加
composer validate --strict和composer check-platform-reqs，早于部署发现问题
最常被忽略的一点：很多冲突源于开发机本地装了全局 Composer 插件（如 hirak/prestissimo），它们可能修改依赖解析逻辑。遇到诡异冲突，先在干净 Docker 环境里复现 —— 那里没有你的 ~/.composer/config.json 干扰。
