composer依赖冲突需先用composer why-not定位阻塞源，输出为空说明目标版本未被依赖图反对，常见原因包括版本不存在、拼写错误、php/扩展不满足或lock损坏；缩进最深行才是真卡点，多源于require-dev或私有包，应配合--with-dependencies精准更新并git diff验证。
别先删 vendor 或改 composer.json —— 你得先搞清谁在拦，再决定降谁。
why-not 输出为空？说明冲突不在依赖图里
这不等于“没问题”，而是目标版本没被任何现有包显式反对。常见原因：
- 包名或版本号拼错，比如
monolog/monologg或漏掉冒号写成monolog/monolog 3.0.0 - 目标版本根本不存在于 Packagist（查一下官网确认
monolog/monolog:3.0.0是否已发布） - PHP 版本、扩展（如
ext-curl）或minimum-stability设置不满足，这些不会出现在why-not输出中 -
composer.lock损坏或缺失，先跑composer update --dry-run触发元数据拉取
why-not 输出里缩进最深的那行才是真卡点
它往往藏在 require-dev 或私有 SDK 里，而不是你一眼看到的 Laravel 或 Symfony：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 输出末尾带
(required by myapp/sdk v2.1)？立刻进./packages/myapp-sdk/目录再跑一次composer why-not - 看到
dev-main或dev-fix-branch？那是半年前为调试加的临时引用，至今钉在composer.json里没清理 - 某行末尾是
(conflict with php: ^8.2)？不是包的问题，是你本地 PHP 还是 8.1，得升级环境或调config.platform.php
看到 conflict with foo/bar (>=2.0) 别急着删 foo/bar
那个 conflict 字段是 foo/bar 自己写的硬拦截规则，不是它在拦你，而是它被别的包拉进来后触发了封杀：
- 先看它上面一行：谁
requires了foo/bar？比如spatie/laravel-backup强绑了foo/bar:^1.5 - 再往上翻：那个包又依赖谁？可能最终卡在
symfony/console的版本分歧上 - 用
composer show -t | grep "foo/bar"确认它是否真被锁死，以及锁定版本是否可松动 - 如果要降级，必须用
composer update foo/bar --with-dependencies，不能加引号、不能带^
为什么 --with-dependencies 是唯一可控的降级方式
默认 composer update 是全局重算，SAT 求解器容易卡住，还可能把 laravel/framework 从 v10.32 升到 v10.33，顺带卷走一堆依赖：
-
composer update foo/bar --with-dependencies只影响foo/bar和它的直系依赖（如psr/log），其他包不动 - 执行后立刻
git diff composer.lock，确认改动范围是否符合预期 - 若提示 PHP 版本不满足（如
foo/bar:2.0.0要 PHP >=8.1），说明环境不匹配，不是命令问题 - 别写
"foo/bar": "^1.25 || ^2.10"—— 这等于放任 Composer 随机选，但你的代码大概率只兼容其中一套 API
真正麻烦的从来不是命令怎么敲，而是缩进最深那一行里那个你早忘了的 dev-fix-branch，或者 require-dev 里悄悄拉进来的 phpunit/phpunit 对 PHP 版本的强要求。
