在 composer.json 中设置 "conflict" 字段是为了明确声明当前包与某些其他包（或版本范围）不兼容，从而让 Composer 在安装或更新时主动报错，阻止产生冲突的依赖组合。
在 composer.json 中设置 "conflict" 字段，是为了**明确声明当前包与某些其他包（或版本范围）不兼容**，从而让 Composer 在安装或更新时主动报错，阻止产生冲突的依赖组合。这不是被动检测，而是提前设防。
conflict 字段的基本写法
它是一个对象，键是包名，值是版本约束字符串（支持通配符、比较符等），语法和 require 一致：
"conflict": {
"monolog/monolog": "^2.0",
"phpunit/phpunit": "<9.0 || >=10.0",
"laravel/framework": "8.*"
}
上面表示：本包不能与 Monolog 2.x 共存；不能与 PHPUnit 小于 9.0 或大于等于 10.0 的版本共存；也不能与 Laravel 8.x 共存。
什么情况下该用 conflict？
-
API 不兼容升级：你写的扩展包只适配 Guzzle 6，而 Guzzle 7 重构了核心接口，就应写
"guzzlehttp/guzzle": "^7.0" - 运行时互斥：两个包都试图重写同一个全局函数或类（如某些旧式“helper”包），可直接冲突对方包名
-
PHP 或扩展限制：你的包依赖
ext-gmp，但某个旧版paragonie/random_compat在启用 GMP 时会出错，可冲突其问题版本 -
避免误装测试工具到生产环境：比如你发布的是一个生产级 SDK，可冲突
"phpunit/phpunit": "*"防止被意外引入
配合 replace 和 provide 更精准控制
conflict 单独用有时不够灵活。常见组合：
- 用
"replace"声明你已替代某个包（如 fork 后重命名），同时"conflict"原包对应版本，防止两者并存 - 用
"provide"声明你实现了某虚拟包（如"psr/log-implementation"），再"conflict"其他实现（如"monolog/monolog"）来强制排他 —— 这适合构建轻量运行时
调试与验证技巧
设置后别忘了验证是否生效：
- 运行
composer install或composer update，故意引入冲突包，看是否报类似Your requirements could not be resolved...的错误 - 用
composer prohibits vendor/conflicting-package查看谁在阻止安装该包（可用于反向排查） - 注意：conflict 不影响 require-dev，如需在开发时也限制，要单独在
require-dev里处理或加脚本检查
