conflict 字段用于在 composer install/update 时静态检查并阻止指定包版本被安装，本质是声明式黑名单；它不解决依赖冲突，也不影响间接依赖，需精确匹配包名和版本约束（支持^、~、!=、=等），误配将导致失效。
conflict 字段到底防什么？
conflict 不解决依赖冲突，它只在 composer install 或 composer update 时做静态检查：一旦当前已解析出的依赖图中，出现了与 conflict 声明匹配的包（含版本），Composer 就直接报错中断，不让你继续。它本质是「声明式黑名单」，不是自动降级或跳过机制。
常见误用场景："conflict": {"monolog/monolog": "1.23.0"} 想阻止某个坏版本，但实际项目里装的是 monolog/monolog:^2.0 —— 这条声明完全不生效，因为版本不匹配。
- 必须精确匹配包名 + 版本约束（支持
^、~、!=、等） - 只对最终锁文件（
composer.lock）里实际被安装的包起效 - 不会影响依赖解析过程本身，只是最后一步“验收”
怎么写才真正拦截住问题版本？
关键在版本约束写法要覆盖真实安装路径。比如某次更新后 guzzlehttp/guzzle 的 7.5.0 引入了破坏性变更，而你的代码调用了已被移除的 GuzzleHttp\Client::get() 方法——这时应拦截所有含该问题的版本：
{
"conflict": {
"guzzlehttp/guzzle": ">=7.5.0 <7.5.2",
"guzzlehttp/guzzle": ">=7.6.0 <7.6.1"
}
}
注意这里用了两条独立规则（Composer 支持数组值），而不是合并成 "7.5.0 - 7.5.1 || 7.6.0 - 7.6.1" —— 因为 Composer 的版本解析器不支持逻辑或写法，只认单个约束字符串。
- 用
>=和组合比 <code>!=更可靠（!=7.5.0无法阻止7.5.1） - 如果要拦截整个大版本（如所有
8.x），写"guzzlehttp/guzzle": "^8.0"即可 - 别忘了测试：删掉
vendor/和composer.lock，再composer install看是否真报错
conflict 和 require / replace / provides 有什么区别？
require 是「我要这个」，conflict 是「我绝对不要这个」，二者定位完全不同。它和 replace（声明自己替代某个包）、provides（声明提供某虚拟包）也无交集——后两者影响依赖解析策略，conflict 只做终局校验。
-
conflict不会改变依赖树结构，哪怕你写了"conflict": {"php": "，Composer 仍可能选一个要求 <code>php: >=8.0的包，只要它没违反你的冲突规则 - 想真正限制 PHP 版本，应该用
"platform": {"php": "8.1.0"}配合config.platform-check - 多个包同时冲突？直接列在
conflict对象里，每项独立判断
容易被忽略的边界情况
最常踩的坑是：以为 conflict 能防止间接依赖引入问题包。实际上，如果 A → B → C，而你在 A 的 composer.json 中写 "conflict": {"C": "1.0.0"}，但 B 显式 require 了 C:^1.0，且 Composer 解析出的 C 版本是 1.0.1，那这条 conflict 就不会触发——因为你没写 "C": "1.0.*" 或 "C": ">=1.0.0 。
- 冲突检测只看最终安装结果，不看依赖路径
- 私有包或 fork 包要注意名称是否一致（
"myorg/guzzle-http"≠"guzzlehttp/guzzle"） - CI 环境中若用了
--ignore-platform-reqs，conflict仍生效，但平台约束（如 PHP 版本）会被跳过
真正起作用的前提，是你写的版本范围，恰好覆盖了 lock 文件里那个被实际安装的版本号。多打几次 composer show guzzlehttp/guzzle 确认实际装的是啥，比凭感觉写约束靠谱得多。
