Composer更新失败主因是版本约束互斥，非网络问题；应使用composer why-not定位阻塞链、composer show --tree查看真实依赖结构，并用composer update加--with-dependencies精准更新。
Composer 更新失败，八成不是网络问题，而是你写的版本约束在互相打架。删 vendor、清缓存、换镜像源，这些操作不会让冲突消失，只会让你重跑一遍失败过程。
用 composer why-not 定位谁在拦路
报错里出现 don’t install xxx 或 it is not possible to install xxx，别猜，直接查源头。命令必须带完整版本号，比如：
-
composer why-not guzzlehttp/guzzle:^8.0.0—— 写^8可能匹配不到元数据，必须写明^8.0.0或8.0.0 - 输出是反向链：最后一行是你
composer.json里的声明，往上逐行看哪条required by提出了互斥要求，那就是冲突根因 - 输出为空？检查
require-dev—— 很多冲突来自phpunit/phpunit或mockery/mockery锁死了老版sebastian/exporter，间接卡住symfony/console
用 composer show --tree 看真实依赖结构
composer.json 是你写的“愿望清单”，composer show --tree 才是 vendor/ 和 composer.lock 里的真实快照。它能暴露你根本没意识到的间接路径：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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"—— 查谁引入了这个包 -
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"—— 过滤关键依赖段 - 看到
(replaced)或(provided)？得去那个包自己的composer.json里确认它到底替代了什么，是否真能覆盖你要的依赖
定点更新必须加 --with-dependencies
全量 composer update 容易触发 SAT 求解器卡死，尤其依赖多的项目。升级单个包不带参数，Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来：
- ✅ 正确：
composer update monolog/monolog --with-dependencies—— 只动它和直系依赖 - ❌ 错误：
composer update "monolog/monolog:^3"—— 引号 +^会让 Composer 自己找“最新兼容版”，不是你要的3.0.0 - 跨主版本降级（如从
guzzlehttp/guzzle:^8.0切回7.4.5），必须在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他
最常被忽略的一点：依赖冲突不是“某个包太旧”，而是多个包对同一个依赖提出的版本区间没有交集。哪怕只改一行 composer.json，也可能牵出三层间接依赖的连锁反应。动手前先看树，动手后先验锁文件——这才是不反复踩坑的关键。
