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
