conflict 字段是声明式冲突检测机制，仅在依赖解析时对新版本报错，不自动降级或绕过；需用标准版本约束语法，与 require 共同参与 SAT 求解，交集为空则解析失败。
conflict 字段不是“解决冲突”的工具，而是提前报错的声明
它不帮你自动降级、替换或绕过依赖，只在 composer install 或 composer update 过程中，当依赖解析器发现某个包（无论直接 require 还是间接引入）的版本落在你写的 conflict 范围内时，立刻中断并报错。
常见错误现象：composer require foo/bar 成功，但后续 composer update 突然失败，提示 “Your requirements could not be resolved”，却没看到 conflict 关键字——那很可能是因为你新加的包触发了另一个已安装包的 conflict 规则，而那个包不在你的根 composer.json 里，是在它的 composer.json 中声明的。
- conflict 只对「正在解析的新版本」生效，不会回溯检查已锁死的
composer.lock中旧版本是否违规 - 如果你手动
require了一个兼容版本，它不会被阻拦；只有当你试图引入一个明确被 conflict 排除的版本时才报错 - 它不阻止 Composer 尝试绕过冲突（比如降级父依赖），所以有时你会看到“找不到满足条件的版本”而不是直白的 conflict 报错
怎么写才真正生效：包名 + 标准版本约束
格式必须是键值对："conflict": { "vendor/package": "版本约束" }。版本约束必须用 Composer 原生语法（^、~、>=、=、*），不能写正则、模糊描述或分支名（如 "dev-master" 无效）。
使用场景举例：你的包重写了 JsonEncoder，和 bad-vendor/legacy-json 类名冲突，但只在 v1.x 下有问题：
"conflict": {
"bad-vendor/legacy-json": "^1.0"
}
-
"laravel/framework": "*"表示完全禁止 Laravel，慎用——它会堵死所有集成路径 -
"php": "<8.1 || >=8.2.5"是合法的，因为php是 Composer 认可的平台包名 -
"ext-redis": "*"不能靠 conflict 检测扩展是否启用，它只参与依赖解析，不查运行时环境
conflict 和 require 同时存在时，Composer 怎么决策？
它们不是谁优先的问题，而是被一起喂给 SAT 求解器做逻辑交集判断。Composer 会尝试找一个同时满足 require 范围、又避开 conflict 范围的版本。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
例如：
"require": {
"symfony/http-foundation": "^5.0"
},
"conflict": {
"symfony/http-foundation": "<5.4"
}
最终可接受的版本是 >=5.4 && <6.0（即 ^5.0 和 >=5.4 的交集）。
- 如果交集为空（比如
"require": "^2.0"+"conflict": "^2.3"），Composer 直接报错无法解析 - conflict 不会“覆盖”require，也不会让 Composer 主动选低版本——它只是划出一块禁区
- 如果你的包同时 require 某个包又 conflict 它的子集，说明你逻辑自相矛盾，得先理清兼容边界
容易被忽略的坑：platform 和 lock 文件让它“假装看不见”
如果你在根项目设置了 "config": { "platform": { "php": "8.1.0" } }，那么 "conflict": { "php": "8.0.*" } 就不会触发——因为 Composer 按照你“假装”的平台环境来校验，而非真实 PHP 版本。
正确做法是开启 "config": { "platform-check": true }（默认已开启），它会在 composer install 后额外跑一次真实环境校验。
- conflict 对
ext-*、lib-*的声明也受platform影响，别只盯着包名 - 如果你把冲突包写在
require-dev里，它通常不会出现在最终依赖图中，conflict 很可能压根不触发 - 发布前务必用
composer require vendor/conflicting-package:版本手动模拟一次会撞墙的操作，看错误里有没有conflict字样
最麻烦的情况不是写错 syntax，而是写得太宽或太窄：宽了让人没法集成，窄了漏掉已知问题版本。它是个契约，不是补丁。
