conflicts 字段防运行时兼容问题，如类重写、事件监听器冲突等；需写具体版本约束才生效，如"conflicts": {"phpunit/phpunit": ">=10.0.0"}。
conflicts 字段到底防什么
不阻止安装，只在
或
时检查已解析出的依赖图——如果某个被声明为冲突的包最终被拉进依赖树（无论直接还是间接），Composer 就会中止并报错：
它防的是「运行时才暴露的兼容问题」，比如两个包都重写了同一个类、都注册了同名的 Symfony 事件监听器、或都修改了全局
。这类问题不会在
阶段报错，但上线后突然崩。
怎么写 conficts 才真正生效
必须写具体版本约束，不能只写包名。写成
看似激进，但实际几乎没用——因为 Composer 默认允许
匹配任意版本，而冲突检测是精确比对已安装版本是否落在该约束范围内。
✅ 正确：只封掉已知不兼容的版本区间，例如
✅ 正确：封死整个大版本（如果确认全不兼容），例如
❌ 错误：只写包名
—— 这会被忽略
❌ 错误：用
当通配符封全部版本，
—— Composer 不认这种写法，等价于没写
conflicts 和 replace、require 的关键区别
是纯声明式防御，不改变依赖解析逻辑；
会从依赖图中“抹掉”被替换的包（常用于 fork 替代）；
是主动拉取。三者混用极易翻车。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
如果你用
声明替代了
，再在
里写它，Composer 会警告：「You cannot conflict with a package you replace」
如果你在
里锁了
，又在
里写
，Composer 会直接拒绝解析——哪怕
明确落在冲突范围内
冲突检测发生在所有
解析完成之后，所以它无法阻止你主动
一个自己声明冲突的包
CI 里必须跑
composer
update --dry-run
只在依赖解析阶段触发，本地开发时可能因缓存、旧 lock 文件或手动
绕过检测。CI 流程里光跑
不够。
必须加一步：
。这会让 Composer 强制重新解析整个依赖图，真实模拟新环境首次安装场景，把隐藏的冲突暴露出来。
容易被忽略的一点：如果项目用了
或自定义
，
仍会受其影响——得确保 CI 的 platform 配置和目标部署环境一致，否则冲突可能漏检。
conflictscomposer installcomposer updateYour requirements could not be resolved to an installable set of packages.$GLOBALSautoload"conflicts": {"monolog/monolog": "*"}*"conflicts": {"phpunit/phpunit": ">=10.0.0 "conflicts": {"guzzlehttp/guzzle": "^7.0"}"conflicts": {"laravel/framework": {}}*"conflicts": {"symfony/console": "*"}conflictsreplacerequirereplacesome/packageconflictsrequire"foo/bar": "1.2.3"conflicts"foo/bar": "^1.2"1.2.3requirerequireconflictsrequirecomposer installcomposer update --dry-run --no-interactionplatform-checkconfig.platform--dry-run