conflict字段是提前报错的声明机制，仅在install/update解析完成、写入vendor前校验实际选中版本；须置于根composer.json中，用标准语义化版本语法（如"^7.5"），分支名、*等无效。
Composer 的 conflict 字段不是解决冲突的工具，而是提前报错的声明机制；它只在 composer install 或 composer update 依赖解析完成、准备写入 vendor/ 前一刻触发校验，且仅对「实际被选中的版本」生效。
conflict 字段写在哪、怎么写才真正生效
它必须放在项目根目录的 composer.json 中，与 require 同级。不能写在子包、插件或 require-dev 的配置里，Composer 不会递归读取依赖包内部的 conflict。
- 正确格式：
"conflict": { "guzzlehttp/guzzle": "^7.5" } - 版本约束必须用 Composer 原生语法：
^、~、>=、=、!=都可以，但dev-main、1.x-dev、*（通配符）均非法 -
"php": "8.2"不严谨，应写成"php": ">=8.2.0"或"php": "8.2.*"，否则可能被忽略 - 平台扩展如
ext-redis可以声明，但仅参与解析，不检查运行时是否真实启用
为什么写了 conflict 却没报错？常见失效场景
这不是 bug，是 Composer 解析逻辑的自然结果：它只校验「最终被选中安装的版本」是否落在 conflict 范围内，其余情况一律静默跳过。
- 已锁在
composer.lock中的旧版本不会触发校验，哪怕它本该被禁止 - 手动执行
composer require vendor/package:1.2.3成功，是因为你显式指定了兼容版本，conflict不拦截合法请求 - 间接依赖（如 A → B → C）未被实际选中时，
conflict无机会介入；只有当 B 的版本松散（如^2.0），且解析器最终挑出 C 的冲突版本，才会失败 - 运行
composer update时若composer.lock存在，Composer 默认不重算全图，需加--with-all-dependencies或先删 lock 文件
conflict 和 require 共存时，Composer 怎么决策？
它们不是谁优先的问题，而是被一起喂给 SAT 求解器做逻辑交集判断——Composer 尝试找一个版本，既满足 require 的范围，又完全避开 conflict 的范围。
- 例如：
"require": {"monolog/monolog": "^3.0"}+"conflict": {"monolog/monolog": "^3.5"}→ 实际可选区间为3.0.0–3.4.x - 若交集为空（如
require要^2.0，conflict排除所有2.x），Composer 直接失败，报Your requirements could not be resolved，不提示替代方案 - 报错信息中通常不出现
conflict字样，需加-v查看Conclusion行，或用composer why-not vendor/package:version定位阻断链 - 别和
replace混用同一包：既replace又conflict会让 Composer 困惑，大概率直接退出
容易被忽略的全局影响和平台陷阱
conflict 是全局生效的，不区分 require 还是 require-dev，只要某个包出现在最终依赖图里，就受约束；而 config.platform 可能掩盖真实环境冲突。
- 开发依赖里的包（如
orchestra/testbench）可能间接拉入被conflict的包，即使你部署时用了--no-dev，它仍参与解析 -
"config": { "platform": { "php": "8.1.0" } }会让 Composer 假装运行在 PHP 8.1，导致"conflict": {"php": ">=8.2.0"}失效——务必确保config.platform.php与php -v一致 - 私有模块若通过
path类型引入，它的conflict不会自动继承到主项目；但若它被其他包 require，其约束就会进入全局求解 - 别用
conflict替代合理的require约束优化，比如“避开某个有 bug 的小版本”，应优先收紧require而非加排斥规则
