Composer 卡在 Updating dependencies 主因是依赖解析陷入高复杂度回溯或版本冲突死锁；应优先用 composer why-not 定位冲突，再分步执行 --no-update 和 --with-all-dependencies，并配置国内镜像提速。
Composer 安装扩展包卡在 Updating dependencies 界面，大概率不是网络问题，而是依赖解析陷入高复杂度回溯或遇到版本冲突死锁。直接杀进程重试只会重复踩坑。
为什么 composer install 或 composer require 会卡在更新依赖阶段
Composer 的依赖求解器（SAT solver）在解析 composer.json 中所有包及其版本约束时，可能面临指数级组合爆炸。尤其当项目中存在：
- 大量未锁定的开发依赖（如
"phpunit/phpunit": "^9"而非"^9.6.13"） - 多个包对同一底层库（如
symfony/polyfill、psr/cache）提出互斥的版本要求 - 启用了
minimum-stability: dev或大量@dev标签 - 本地
composer.lock损坏或与composer.json不一致
快速跳过卡顿：用 --no-update + --with-all-dependencies
不强行让 Composer 实时求解整个图，而是分步控制：
- 先添加包但跳过依赖更新：
composer require vendor/package --no-update
- 再用更宽松策略安装依赖（跳过冲突检测中的部分严格路径）：
composer update --with-all-dependencies
- 若仍卡住，加
-v查看最后解析到哪个包：composer update --with-all-dependencies -v
，然后针对性排除
永久提速：禁用 Packagist 元数据预加载和启用并行下载
默认 Composer 会同步远程元数据（尤其是 Packagist），在首次或大更新时非常耗时。可通过配置跳过：
- 关闭自动元数据刷新：
composer config -g repos.packagist.org.allow_ssl_downgrade false
（防止降级重试） - 启用并行下载（PHP 7.4+）：
composer config -g fxp-asset.installer-paths {"npm-asset-library":"./vendor/npm-asset","bower-asset-library":"./vendor/bower-asset"}（仅限旧版 fxp/composer-asset-plugin；新版推荐用composer config -g allow-plugins true后搭配composer require --dev composer/installers） - 最有效一招：强制使用国内镜像并缓存元数据：
composer config -g repo.packagist composer https://packagist.phpcomposer.com
（注意：该镜像已停，应换为https://packagist.laravel-china.org或https://mirrors.aliyun.com/composer/）
终极排查：用 composer why-not 定位冲突源头
当你明确知道某个包（比如 monolog/monolog）导致卡住，不要猜，直接问 Composer：
composer why-not monolog/monolog:^3.0
它会输出所有阻止该版本安装的已安装包及具体约束条件，例如：
laravel/framework 10.10.0 requires monolog/monolog (^2.8.0)
这时你就知道：要么升级 laravel/framework，要么接受 monolog v2，而不是让 Composer 在后台穷举三天。
真正卡住的从来不是网络，是版本约束之间的隐式循环。盯住 why-not 输出，比反复 clear-cache 有用十倍。
