conflict字段用于声明包版本冲突，防止不兼容或重复功能的包共存。通过在composer.json中配置conflict，可阻止特定版本安装，如限制monolog低于2.0、禁用acme/logger-bundle所有版本及排除symfony/http-foundation的5.0.x系列。适用于替代包互斥、规避破坏性变更和插件宿主冲突场景。需注意其仅影响依赖解析，不自动卸载已存在冲突包，且规则由所有依赖共同生效，应精确设定版本约束并测试验证。
在使用 Composer 管理 PHP 项目依赖时，不同包之间可能会因为版本不兼容或功能重叠导致冲突。为了防止这类问题，composer.json 中的 conflict 字段可以明确声明哪些包或版本不能与当前包共存。
conflict 字段的作用
conflict 是 composer.json 中的一个配置项，用于定义与其他包的版本冲突关系。当 Composer 解析依赖时，如果发现某个已安装或待安装的包在 conflict 列表中，就会抛出错误，阻止安装或更新操作。
这有助于：
- 避免加载两个功能重复的库（如不同实现的日志组件）
- 防止因版本不兼容导致的运行时错误
- 确保项目依赖环境的一致性和稳定性
如何正确使用 conflict 字段
在 composer.json 文件中添加 conflict 节点，格式为一个对象，键是包名，值是版本约束：
{
"require": {
"monolog/monolog": "^2.0"
},
"conflict": {
"monolog/monolog": "<2.0",
"acme/logger-bundle": "*",
"symfony/http-foundation": "5.0.*"
}
}
上面的例子表示：
- 不允许 monolog/monolog 版本低于 2.0（即使 require 指定了 ^2.0，这里进一步加强限制）
- 完全禁止 acme/logger-bundle 的任何版本（* 表示所有版本）
- 排除 symfony/http-foundation 的 5.0.x 系列版本，可能是因为存在已知兼容性问题
实际应用场景
常见于以下情况：
- 替代包互斥：你开发了一个 fork 版本的库（如 myvendor/guzzle-fork），需要防止原版 guzzlehttp/guzzle 同时被加载
- 重大变更规避：某包在特定版本引入破坏性更改，你的代码无法兼容，可用 conflict 排除
- 插件与宿主冲突：某些插件只能运行在特定版本的框架上，超出范围则标记为冲突
注意事项
使用 conflict 时要注意几点：
- 它只影响依赖解析阶段，不会自动卸载已存在的冲突包（需手动处理）
- 冲突规则由所有依赖包共同决定，只要有一个包声明了 conflict，Composer 就会拒绝安装
- 尽量精确指定版本约束，避免误伤合法场景
- 测试环境中应验证 conflict 是否按预期生效
基本上就这些。合理使用 conflict 字段能有效提升项目的依赖安全性，减少“看似能装，运行报错”的问题。虽然不常用，但在关键库中是一个重要的保护机制。
