直接看 composer update --dry-run -v 末尾几行即可定位冲突源头，关键线索是“Found conflicting requirements”及“Because…requires…, and…requires…”类明确语句，反复出现的包名（如 monolog/monolog）大概率是枢纽，Root requirements 段落指出 composer.json 中哪行约束触发崩塌。
直接看 composer update --dry-run -v 的末尾几行，就能定位冲突源头——不是靠猜，是 Composer 自己把“谁在卡谁”写明白了。
报错末尾的 “Found conflicting requirements” 是关键线索
Composer 解析失败时，不会只抛一句 “don’t install xxx”，它会在 verbose 日志末尾明确列出冲突链。比如：
Because package-a v2.1 requires symfony/console ^5.4, and package-b v3.0 requires symfony/console ^6.0, package-a v2.1 and package-b v3.0 cannot be installed together.
这类句子就是真实冲突点，不是推测。重点盯住反复出现的包名（如 monolog/monolog、symfony/console），它们大概率是枢纽包。
- 忽略中间过程日志，直接翻到最后 10 行，那里才是结论段
-
Root requirements段落会指出是你composer.json里哪一行触发了整条链崩塌 - 如果看到
your-project-name出现在冲突路径里，说明是你自己写的约束太窄或互斥
composer why-not 定位“谁在拦路”
当你想升级某个包却失败时，composer why-not vendor/package:version 是最精准的诊断命令。它不模拟安装，而是反向查“为什么这个版本装不上”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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:^3.0或composer why-not laravel/framework:v10.0 - 输出中若出现
your-project-name，说明是你自己的composer.json里写了冲突约束（比如同时 require 了两个不兼容的扩展） - 输出为空？那不是冲突，可能是 Packagist 镜像未同步，或该版本根本不存在于当前稳定通道
- 别用
composer why替代——它只查已安装版本的依赖来源，不回答“为什么不能装”
composer show --tree 揭露间接依赖链
很多冲突藏在第二、三层依赖里。你没写 symfony/console，但 guzzlehttp/guzzle 依赖它，而 phpunit/phpunit 又对它有不同要求——这种嵌套关系只能靠树状展开看清。
-
composer show --tree vendor/package展示该包及其所有上游依赖和锁定版本 - 注意每行末尾的
(locked to X.Y.Z)，表示该版本已被composer.lock固定，删 lock 才可能松动 - 配合
grep快速过滤：例如composer show --tree monolog/monolog | grep "symfony/.*console" - 如果某包在树里出现多次且版本不一致，说明存在隐式冲突，需统一上游约束
别跳过 config.platform 和 PHP 版本检查
Composer 不会主动告诉你“你本地 PHP 是 8.1，但某个包只支持 7.4”，它只会默默把该包从候选列表里剔除，然后报“无法解析”。结果就是你死磕依赖，却漏掉了平台层问题。
- 运行
composer show --platform确认当前环境声明的 PHP 版本、扩展是否与实际一致 - 检查
composer.json顶层的"php": "^8.1"是否被某个 require 包的"php": "^7.4"覆盖 -
config.platform.php是个陷阱：它伪造 PHP 版本供 Composer 解析用，但若设得比实际低（如设成"7.4"），会导致高版本包被错误排除 - require-dev 里的工具（如
phpunit/phpunit）常带更强的 PHP 版本要求，用composer update --no-dev可快速验证是否 dev 依赖拖后腿
真正难处理的从来不是报错本身，而是冲突发生在多层间接依赖之间，且其中一环还锁死了版本。这时候 --dry-run -v 和 why-not 的组合，比删 vendor 和 composer.lock 有用十倍。
