conflict字段仅在composer install/update解析依赖时，当实际解析出的版本落入声明范围才报错；不回溯检查lock文件、不阻止手动require、必须用标准语义化版本语法，分支名和dev前缀无效。
conflict 字段只在 composer install 或 composer update 解析依赖图时起作用，不是运行时检查，也不清理已安装包——写错或滥用反而会让依赖解析失败得更隐蔽。
conflict 什么时候真正报错？
它只在 Composer 尝试把某个包的**实际解析出的版本号**装进项目时，发现该版本落在 conflict 声明范围内，才中断并报错。其他情况全都不触发：
- 已锁在
composer.lock里的旧版本（哪怕本该被冲突规则覆盖）→ 不报错 - 手动执行
composer require guzzlehttp/guzzle:6.5.5成功后没跑update→ 不校验 - 冲突包是间接依赖（比如 A → B → C），而 Composer 能通过降级 B 绕过 C → 可能静默选旧版，不报错
- 写了
"conflict": {"laravel/framework": "dev-main"}→ 无效，分支名不参与匹配
必须用标准语义化版本语法，别写 dev-、main、* 这类模糊标识
conflict 的值必须是 Composer 能解析的版本约束字符串，否则直接被忽略。常见错误写法和对应修正：
-
"guzzlehttp/guzzle": "dev-master"→ 改成"guzzlehttp/guzzle": "^7.0"或"guzzlehttp/guzzle": ">=7.5.0, -
"php": "8.0"→ 不严谨，应写"php": "8.0.*"或"php": ">=8.0.0, -
"monolog/monolog": "*"→ 会禁止所有版本，慎用；真要全禁，明确写"monolog/monolog": " 更安全 - 平台扩展如
ext-json、lib-pcre同样适用，写法一致："ext-json": "
conflict 和 require 冲突时，Composer 不会妥协，直接失败
它不是“建议”或“软限制”，而是硬性契约。如果 require 拉进来的包版本，刚好撞上 conflict 的范围，Composer 就拒绝继续：
- 例如
"require": {"symfony/console": "^6.2"}+"conflict": {"symfony/console": ">=6.2.12"}→ 解析失败，因为 ^6.2 包含 6.2.12 - 解决办法只有两个：放宽
require（如改成"symfony/console": "^6.2.0,），或删掉这条 <code>conflict - 别指望 Composer 自动降级或跳过——它只做逻辑判断，不做策略选择
platform 冲突（如 php、ext-*）受 config.platform 影响，真实环境可能被掩盖
你在本地 PHP 8.3 上写了 "conflict": {"php": ">=8.2.0"}，但 composer.json 里同时有：
"config": {
"platform": {
"php": "8.1.0"
}
}
那这条冲突就失效了——Composer 会假装运行在 PHP 8.1，不再校验你真实的 CLI 版本。CI 环境尤其容易踩这个坑，因为 config.platform 常被用来“固定”构建环境，却意外绕过了你的冲突声明。
