composer why-not 输出需从最后一行倒推阻断源，末尾为根要求，向上每行末尾的 (required by ...) 是追溯起点；常见错误是误将 conflict 规则当卡点，实际冲突常藏于中间两行对同一包的无交集约束。
composer why-not 输出怎么看：从最后一行倒推阻断源
它输出的不是因果链，是拒绝理由链。最后一行才是你 composer.json 里写的根要求（比如 myapp/core dev-main requires guzzlehttp/guzzle ^6.5），往上每行末尾的 (required by ...) 是向上追溯的起点。
常见错误现象：看到某行写 conflict with symfony/console (>=6.0) 就去降级 symfony/console——错。那是它自己声明的 conflict 规则，不是别人在卡它。
- 必须带完整版本号，例如
composer why-not laravel/framework:10.0.0；写^10.0或10.*会报[InvalidArgumentException] Package not found - 如果输出为空，说明这个包根本没在你的
composer.json里声明过，why-not不适用，该换prohibits - 真正卡死的点，往往藏在中间某两行对同一包提出无交集的约束，比如
guzzlehttp/guzzle ^6.5和^7.2
composer show --tree 怎么揪出隐藏依赖路径
它展示的是 vendor/ 和 composer.lock 的真实快照，不是你 composer.json 里写的“理想状态”。很多冲突藏在第二、三层依赖里，靠这个命令才能暴露。
使用场景：你想确认 symfony/console 是被谁引入、是否已被锁死、有没有多条路径拉入不同版本。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer show --tree | grep "symfony/console"，重点看末尾是否带(locked to 5.4.32)——有就说明这个版本已在composer.lock固定，不删 lock 或不用--with-all-dependencies没法松动 - 终端宽度不够会导致缩进错乱，加
| less -S避免换行干扰层级判断 - 同一个包在不同缩进层级反复出现且版本不一致（如
^5.4vs^6.0），基本就是冲突源头 -
require-dev中的包（如phpunit/phpunit）默认参与解析，它们常带高 PHP 版本或扩展要求，却容易被忽略
composer prohibits 比 why-not 更快定位真实拦路虎
why-not 只查你 composer.json 里写了但没装上的包；prohibits 是从你想装却装不上的那个包出发，一层层翻出所有拦路的依赖约束，更接近“真凶画像”。
性能影响：它不触发完整依赖求解，响应更快，尤其适合大型项目。
- 执行
composer require laravel/framework:^11.0失败后，直接跑composer prohibits laravel/framework:11.0.0 - 输出里每行末尾的
(for spatie/laravel-backup v7.2.0)就是真正卡死你的源头，不是模糊地说“某个依赖” - 必须带精确版本号，且只对已发布版本有效；写
^11.0同样报Package not found - 如果输出为空，说明没有包显式
require它，可能来自replace或conflict字段，得查composer.lock或对应包的composer.json
composer update --dry-run -v 看懂冲突链在哪一行
这个命令不改任何文件，但会把 Composer 的整个依赖求解过程摊开给你看。关键不是开头，是末尾几行。
容易踩的坑：不加 -v 参数，你只看到“无法解析”；加了才能看见“谁在拉扯谁”。
- 盯
Because链：比如Because package-a v2.1 requires monolog/monolog ^1.25, and package-b v3.0 requires monolog/monolog ^2.10——这就是无交集的铁证 - 看
Root requirements段落：找出你composer.json里哪条"vendor/name": "^x.y"是整场冲突的起点 - 关注
Found conflicting requirements下列出的具体包名和版本范围，它们才是你要动手调的对象 - 别跳过
--dry-run，它能避免误操作导致composer.lock被意外重写
composer.json，而在某条你没注意的 require-dev 依赖、某个被锁死的中间包、或一个旧版 SDK 对枢纽包（如 symfony/console）的硬性绑定。读输出时，先找最后一行，再逆着 required by 往上推，比凭感觉删包靠谱得多。
