conflict 字段是安装熔断开关而非提示：它在 composer install/update 最后一步校验 lock 文件中的实际版本，匹配即中断；应使用 ">=1.23.0" 而非精确版本避免漏触发。
直接结论：用 conflict 字段声明互斥版本，比删包、改锁、硬升级更可控；但它不解决依赖树矛盾，只做安装前的“熔断”。
conflict 不是提示，是安装熔断开关
很多人把 conflict 当成“友好提醒”，结果加了照样装上问题版本——因为它只在 composer install 或 composer update 最后一步校验已解析出的依赖图。只要最终 composer.lock 里出现了匹配的包+版本，Composer 就立刻中断并报错，不写日志、不降级、不重试。
- 错误写法：
"conflict": {"monolog/monolog": "1.23.0"}→ 实际装的是1.23.1，完全不触发 - 正确写法：
"conflict": {"monolog/monolog": ">=1.23.0 → 覆盖整个问题小版本段 - 别用
!=：它无法阻止1.23.1，而>=1.23.0 可以 - 冲突生效范围是全局的：哪怕你没
require某个包，只要其他依赖（比如phpunit/phpunit）把它拉进来，就会被拦住
什么时候该用 conflict 而不是 require 或 replace
conflict 的真实定位很窄：它只适合「我知道这个版本绝对不能跑」的场景，比如某次更新删了关键方法、破坏了序列化格式、或引入了 PHP 8.2 不兼容的语法。它和 require（我要什么）、replace（我代替谁）逻辑上互不重叠。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想锁定最低版本？用
require："guzzlehttp/guzzle": "^7.5" - 想用 fork 替代原包？用
replace："replace": {"original/package": "self.version"} - 想阻止某个已知崩溃版本？才轮到
conflict，且必须精确命中实际安装路径 - 误配后果严重：加了但没生效，上线后 crash；加错范围（如写成
"^8.0"却忘了自己代码只适配 7.x），直接阻断所有更新
实战中容易漏掉的三个校验点
加完 conflict 别急着提交，先验证是否真起作用。最常被跳过的检查是：
- 删掉
vendor/和composer.lock，再跑一次composer install—— 这是唯一能确认它是否真正拦截的测试方式 - 查
composer show vendor/package确认当前项目里实际装的是哪个版本，再对照conflict规则看是否覆盖到位 - 运行
composer why-not vendor/package:bad-version，看输出里有没有你的conflict条目被引用（它会出现在“because”链末尾）
真正难的从来不是加一行 conflict，而是判断「这个版本到底能不能跑」——它需要你读 changelog、跑单元测试、甚至翻 PR diff。一旦判断失误，要么白加，要么卡死整个依赖更新流程。
