conflict 在 composer install/update 时，当实际解析出的版本落入其声明范围才报错；分支名无效，需用标准版本约束；与 require 冲突则直接失败。
不是防安装开关，而是契约式声明：它只在依赖解析阶段发现版本匹配冲突规则时中断并报错，且仅对当前解析路径生效。
conflict 什么时候会真正报错？
它只在
或
过程中触发，前提是 Composer 正在尝试安装/升级某个包，而该包的**实际解析出的版本号**落在
声明的范围内。
已锁在
中的旧版本，不触发 —— 即使它本该被冲突规则覆盖
手动
成功后，只要没 run update，也不会校验冲突
如果冲突包是间接依赖（比如 A → B → C），而 B 降级就能绕过 C，Composer 可能选降级而非报错
写
无效 —— 分支名不参与版本解析，必须用
、
这类标准约束语法
conflict 和 require 同时存在，谁说了算？
Composer 先尽力满足
，再检查是否违反
。两者无法共存时直接失败，不妥协、不提示替代方案。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
例如：
→ 解析器找不到既 ≥3.0 又
错误信息里会出现类似
，并带
关键字
别指望它“提醒用户注意”，那是文档或
的事；
只用于强互斥场景（如两个包提供同名类且不兼容）
怎么验证 conflict 是否生效？
最可靠的方式是模拟一次它该拦住的操作，然后看错误是否含
：
删掉
，执行
—— 检查是否因冲突中断
或运行
，观察是否立即报错
若想确认某版本为何没装上，用
，它会列出所有阻断链，包括来自
的那一环
注意：不要加
测试，它会跳过包括
在内的全部约束校验
的边界很窄：它不干预已锁定状态，不阻止手动引入，也不主动排除替代路径。真正起作用的，永远是你在
里写的那几行精确约束，以及你执行的那条命令所触发的解析上下文。
conflictcomposer installcomposer updateconflictcomposer.lockcomposer require vendor/package:1.2.3"conflict": {"laravel/framework": "dev-main"}=10.0^9.0requireconflict"require": {"monolog/monolog": "^3.0"}, "conflict": {"monolog/monolog": "^3.5"}Conclusion: don't install monolog/monolog v3.5.0conflictrequireconflictconflictcomposer.lockcomposer installcomposer require some/conflicting-package:^2.0composer why-not some/package:2.0conflict--ignore-platform-reqsconflictconflictcomposer.json