conflict 字段用于声明本包与某些版本的其他包互斥，安装时若检测到冲突则报错中止；它不参与依赖解析，仅在解析完成后校验，且仅对直接消费者生效。
composer.json 里的 conflict 字段到底起什么作用
conflict 不是让 Composer 自动帮你“绕开”冲突，而是声明「我这个包和某些版本的其他包水火不容」。一旦用户安装时触发了该规则，Composer 就会直接报错并中止安装，而不是静默降级或跳过——它是个硬性拦截器，不是规避策略。
常见误解是把它当「自动兼容开关」，实际它只做一件事：在 composer install 或 composer update 过程中，检查已解析出的依赖图里是否存在违反 conflict 声明的组合，有就抛出类似这样的错误：
Conflict detected: doctrine/orm v3.0.0 conflicts with myvendor/mylib ^2.1
- 它不参与版本选择算法，不影响
require的解析逻辑 - 它只在依赖解析完成后、写入
vendor/前一刻才校验 - 不能用来“推荐替代包”，那是
replace或provide的职责
conflict 的写法和常见参数陷阱
语法结构简单，但几个细节极易踩坑：
- 键名是包名（
vendor/name），值是版本约束字符串，支持^、~、!=、>等所有 Composer 版本运算符 - 不能用通配符如
*匹配包名；只支持精确包名 - 版本约束中若含空格（比如
"= 3.0.0"），必须用双引号包裹整个值 - 不支持布尔表达式嵌套，如
"(>=1.0.0 && =3.0.0"是非法的，得拆成多条
正确示例：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
{
"conflict": {
"monolog/monolog": "<2.8.0",
"phpunit/phpunit": ">=10.0.0",
"ext-xdebug": "*"
}
}
什么时候该用 conflict，而不是改 require 或加 replace
核心判断标准：你是否能明确指出「只要这个包以某个版本存在，我的代码就必然崩溃或行为异常」。
- PHP 扩展缺失导致 fatal error？用
"ext-gd": "*"拦住没装 GD 的环境 - 某上游包在 v2.5.0 修复了一个关键 bug，但 v2.4.x 全系列有内存泄漏？写
"upstream/lib": " - 你的包重写了
symfony/console的某个命令类，且与 v6.2+ 的新签名不兼容？那就"symfony/console": ">=6.2.0" - 想提示用户「请用 A 包代替 B 包」？别用
conflict，改用replace+provide组合
真实项目中容易被忽略的边界情况
很多团队加了 conflict 却没生效，往往卡在这几个点：
-
conflict只对当前 package 的直接消费者生效；如果它是被嵌套在三级依赖里（比如 A → B → C，你在 C 中声明 conflict），那 A 的composer install不会校验 C 的 conflict 规则 - 本地开发时用
composer require --dev安装 dev-only 包，而conflict默认也作用于 dev 依赖，除非你显式设"minimum-stability": "stable"并关闭"prefer-stable": true - 使用
composer update --with-all-dependencies时，冲突可能被“绕过”——因为 Composer 会尝试放宽约束重算依赖图，此时conflict仍会触发，但错误信息可能指向更上游的包，排查路径变长
最稳妥的做法：把 conflict 当作最后一道闸门，配合单元测试覆盖关键冲突场景，并在 CI 中强制跑 composer validate 和 composer install --no-dev 双重验证。
