Composer依赖冲突本质是约束无法同时满足，需用composer why-not定位阻断链、检查composer.lock实际版本，而非盲目清理或绕过校验。
依赖冲突不是“装不上”，而是 Composer 明确告诉你：当前所有约束条件合起来，找不到一组能同时满足的版本组合。删 composer.lock 或硬加 --ignore-platform-reqs 只会掩盖问题，甚至让环境更不可控。
看懂报错末尾的 “Conclusion” 和 “Root requirements”
Composer 报错里最值得盯的是最后几行，尤其是以 Conclusion: 开头和 Root requirements: 标注的部分。它不讲道理，只摆逻辑链：
-
Conclusion: don’t install thinkphp/framework v6.0.10—— 这不是拒绝你，是推导结果；真正卡住的，往往是它上面一行的Because package-x v2.1 requires symfony/console ^5.4 -
Root requirements: ["topthink/think-swoole": "^3.0"]—— 说明你刚写的这行require是整条冲突链的触发点 - 反复出现的包（如
monolog/monolog、guzzlehttp/guzzle）大概率是枢纽，不是源头；要顺着它往上查谁在提要求
用 composer why-not 和 composer prohibits 定向挖根
这两个命令输出的是“拒绝理由链”，不是依赖树，必须倒着读——最后一行才是你的 composer.json 根依赖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer why-not monolog/monolog:^2.0：查为什么装不了 2.x，输出里带conflicts with的那行，才是真拦路虎 -
composer prohibits thinkphp/framework:6.0.10：查哪个已安装包明确反对这个版本，常暴露 TP5 扩展包还锁在^1.0分支 - 注意
require-dev同样参与解析；phpunit/phpunit对symfony/console的约束，可能比你主业务包还狠
改 composer.json 前先查 Packagist 上的真实兼容版本
别猜 ^1.25 || ^2.10 能不能通，去 Packagist 看发布记录，找一个被上下游共同接受的中间版（比如 v2.9.3 既满足 A 的 ^2.0，又满足 B 的 >=2.8.0）。
- 改完别全量
composer update；用composer update monolog/monolog --with-dependencies精准升级，避免连带崩掉其他包 - 如果某包写的是
*或dev-master，立刻换成具体稳定版（如"2.10.2"），模糊约束是冲突温床 - 检查
conflict字段：有些包明写"conflict": {"laravel/framework": ">=10.0.0"}，这种不会在 require 阶段警告，只在 resolve 阶段爆
私有仓库失效？大概率漏了 "packagist": false
私有包总从 packagist.org 下载，不是配置没生效，是默认源仍插队到末尾匹配。没有 "packagist": false，私有仓库只是“补充”，不是“替代”。
- 该字段必须是
composer.json根对象的直接子项，不能嵌在repositories里 - 多个私有源共存时，顺序决定优先级：
repositories数组第一个能返回元数据的仓库胜出，后面同名包版本压根不参与比较 - 验证是否命中：运行
composer show -a myorg/utils，看输出中source行标出的 URL 是否是你期望的私有地址
真正难处理的从来不是版本号本身，而是某个包在 composer.lock 里被多层间接依赖锁死，而你根本没在 composer.json 里显式声明过它——这种隐式锁定，只有 composer show --tree 配合 grep 才能揪出来。
