Composer怎么使用conflict字段_Composer如何声明与某些包版本不兼容的冲突关系【方法】-composer-PHP中文网

conflict 字段必须写在项目根目录的 composer.json 中，与 require 同级；格式为 "conflict": { "vendor/package": "=3.0.0" }，仅支持标准版本约束（如 =1.0.0），不支持 dev-master 等非法写法。

composer怎么使用conflict字段_composer如何声明与某些包版本不兼容的冲突关系【方法】

它必须写在项目根目录的 composer.json 里，和 require 同级，不是插件或子包的配置项。Composer 只在安装/更新时读取当前项目的 composer.json 中的 conflict，不会递归检查依赖包里的 conflict。

格式很简单："conflict": { "vendor/package": "=3.0.0" }。注意版本约束写法要合法，不能用 ^ 或 ~ 以外的模糊写法（比如 dev-master）——Composer 会直接报错 Invalid version constraint。

最常见的情况是：写了 conflict，但 composer install 还是成功了，甚至装上了被声明冲突的包。这不是 bug，而是 Composer 的解析逻辑导致的。

conflict 只在「依赖解析完成、准备写入 vendor 前」校验，如果冲突包根本没被选中（比如 require 里没它，也没其他依赖拉它），那 conflict 就没机会触发
如果你用 composer require vendor/package:1.2.0 显式安装一个被 conflict 的版本，Composer 会直接拒绝，但如果是间接依赖（比如 A 依赖 B，B 依赖 C，而你在 conflict 里写了 C），就得看 B 的版本是否锁死——松散版本（如 ^1.0）可能绕过你的冲突规则
运行 composer update 时，如果 composer.lock 已存在且含冲突包，Composer 默认不会重算依赖，得加 --with-all-dependencies 或删 lock 文件再试

它们共存时，优先级和语义完全不同，混用容易出意料的结果。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

replace 是“我代替你”，Composer 会把被 replace 的包从依赖图里整个剔除；conflict 是“你不能存在”，两者逻辑相反，不要对同一个包又 replace 又 conflict
provide 声明能力（如 "psr/log-implementation": "1.0"），和 conflict 无直接交互，但如果你 conflict 了某个提供相同能力的包，而另一个包又 provide 同样能力，Composer 不会自动切换——它只管装不装，不管能力是否被满足
require-dev 里的包也会受 conflict 约束，哪怕只是开发时用。所以如果你在 dev 里用了某测试工具，而它依赖一个你 conflict 掉的包，composer install --no-dev 能绕过，但 --with-all-dependencies 会把它揪出来

conflict 是声明式防御，被动生效；真要确保环境干净，得靠组合手段。

用 composer prohibits vendor/package 查谁在拉那个包，比盲写 conflict 更准
在 CI 中加检查：运行 composer show vendor/package + || echo "not installed"，比依赖解析阶段的 conflict 更确定
如果目标是阻止某包进入生产环境，用 require-dev 隔离 + composer install --no-dev 是更可控的方式；conflict 更适合防止意外兼容问题（比如两个包都改了同一类的全局函数）

conflict 的真正价值不在“拦住安装”，而在让冲突显性化——一旦出现，错误信息明确指出哪个包、哪个版本、为什么被拒。但它的触发前提是 Composer 真的尝试去装那个版本，而这取决于整个依赖图的收敛结果，不是写上就万事大吉。