conflict字段不会自动阻止安装，仅在依赖解析时与require共同参与sat求解；若二者版本范围交集为空，则报“your requirements could not be resolved”错误。
conflict字段到底会不会阻止安装
不会自动阻止，但会在依赖解析失败时成为报错原因之一。它不参与 solver 的主逻辑计算，只在版本交集为空时被当作一个约束条件加入判断——也就是说，conflict只有和require共同导致无解时才“生效”。你看到Your requirements could not be resolved，未必是某个包明写了conflict，而更可能是它声明的conflict与你当前require范围叠加后无交集。
常见错误现象：
- 手动
composer require foo/bar成功，但后续composer update失败，报错里却没提conflict——大概率是foo/bar的composer.json里写了"conflict": {"php": ">=8.3"}，而你升级了 PHP 或其他包间接引入了冲突组合 -
composer install成功，但composer check-platform-reqs报conflict警告——说明它只在运行时校验环节起提示作用，不是安装拦截器
怎么确认某个包有没有写conflict
默认composer show vendor/package不显示conflict字段，必须加-s或转 JSON 查。
- 查单个包：
composer show -s vendor/package，向下滚动找conflict键；为空或没出现即未声明 - 批量/脚本化检查：
composer show --format=json vendor/package | jq '.conflict'，返回null表示未定义，否则输出类似{"php": ">=8.3"} - 注意：
conflict只存在于包自己的composer.json中，不会被继承或合并到根项目，所以不能靠看自己项目的composer.json来判断间接依赖是否冲突
conflict和require同时存在时，Composer怎么算
它们被一并喂给 SAT 求解器，做逻辑交集运算：求一个版本，既落在require范围内，又不在conflict范围内。没有交集就失败。
- 例如：
"require": {"monolog/monolog": "^2.0"}+"conflict": {"monolog/monolog": "2.9.1"}→ 仍可装 2.0.0、2.10.0 等，只要避开 2.9.1 - 但若写成
"conflict": {"monolog/monolog": "^2.0"}，则整个 2.x 都被排除，与require直接矛盾，必然失败 - 通配符
*很危险："conflict": {"laravel/framework": "*"}等于禁止所有 Laravel 版本，几乎无法满足任何集成场景
排查conflict引发的冲突该用什么命令
别猜，用composer why-not反向定位谁在封杀。这是最直接、最可靠的手段。
- 执行
composer why-not vendor/package:version（如composer why-not laravel/framework:^11.0），输出的是拒绝链，要从最后一行倒着读 - 如果某行末尾带
(conflict with foo/bar >=2.0)，说明foo/bar的composer.json里写了对应conflict - 配合
composer show -t | grep package验证该包实际被谁拉入，尤其注意require-dev里的包——它们同样参与解析，且常因滞后更新成为隐性锁死源 - 慎用
composer prohibits：它只查“谁在阻止安装”，但不告诉你为什么阻止，信息粒度不如why-not
真正容易被忽略的是：conflict 声明本身不校验真实性，作者可以乱写；它也不检查运行时环境（比如ext-redis是否启用），只管版本号匹配。所以看到 conflict 报错，第一反应不该是“删掉它”，而是确认那个版本组合是否真的不可行——有时候只是作者测试覆盖不足，而非技术上不可能共存。
