卡在Resolving dependencies是本地依赖解析（非HTTP请求），主因是内存不足、SAT求解器回溯或锁文件残留坏URL；应调高process-timeout、设memory_limit≥1.5G、禁用插件，并验证是否实为autoload生成卡顿。
卡在Resolving dependencies时不是HTTP超时
这一步根本没发HTTP请求，而是本地解析composer.json和composer.lock、计算版本约束、回溯冲突依赖——它受process-timeout控制，但更常被内存或CPU卡住。错误里不会出现cURL error 28，也不会有Downloading字样。
常见现象包括：终端停在Resolving dependencies不动、php -d memory_limit=2G composer update仍卡住、-vvv最后几行反复打印Checking <package> for updates</package>。
- 先确认是否真卡住：运行
composer update --dry-run -vvv，看是否能快速输出“Nothing to install, update or remove”——能则说明只是解析慢，不是死锁 - 内存不足是主因：Composer 2.x 解析复杂依赖树时极易 OOM，
memory_limit至少设为1.5G，临时用php -d memory_limit=2G composer update - 禁用插件可提速：全局插件（如旧版
fxp/composer-asset-plugin）会在解析阶段介入，加--no-plugins试试 - 避免
dev-main等模糊版本：它们强制 Composer 去远程查最新 commit，哪怕只查一个包也会拖慢整棵树解析
process-timeout必须调高，且不能设为0
process-timeout是唯一管Resolving dependencies阶段的超时参数，但它不区分“卡在解析”还是“卡在下载”，只要总耗时超限就杀进程。
默认300秒对中小项目够用，但含几十个dev-分支或大量conflict规则的项目，600～1200秒更稳妥。
- 临时生效：用
composer update --timeout=900（注意必须带=，--timeout 900会被忽略） - 永久生效：运行
composer config -g process-timeout 1200，写入~/.composer/config.json - 设为0风险大：某些循环依赖场景下，Composer 会无限递归，进程不退出也不报错，只能
kill -9 - CI 环境务必显式设置：Docker 或 GitHub Actions 中，别依赖全局配置，直接用
COMPOSER_PROCESS_TIMEOUT=1200环境变量
镜像源和缓存对解析阶段无效
换阿里云镜像、清缓存、配 GitHub Token……这些全不影响Resolving dependencies阶段。因为这一步纯本地运算，不碰网络，也不读vendor/或缓存目录。
但有一个例外：composer.lock里若记录了已失效的 dist URL（比如某包从 GitHub 私仓迁出），Composer 在解析时仍会尝试校验该 URL 可达性——这时看似卡解析，实则是卡在 HTTP 请求上。
- 验证方式：加
-vvv后看最后一行是否含GET https://或HEAD https://；若有，说明不是纯解析卡顿，而是锁文件残留了坏链接 - 清理方法：删掉
composer.lock，再跑composer update --lock重生成（不下载包，极快） - 预防：团队协作中，禁止手动编辑
composer.lock，所有变更走composer update或composer require
真正麻烦的是“看起来在解析，其实卡在autoload生成”
有些项目composer update停在Resolving dependencies之后、Installing dependencies之前，-vvv日志却突然断掉——实际是卡在Generating autoload files，但 Composer 没打出这行字。
原因通常是vendor/里存在 symlink（尤其 WSL2 或 Docker volume 场景），PHP 递归扫描时陷入路径循环，或 APCu 未启用导致classmap生成极慢。
- 复现方式：删掉
vendor/，只留composer.lock，再跑composer install --no-scripts；如果这次飞快完成，问题就在 autoload 阶段 - 绕过方案：加
--no-autoloader跳过生成，之后单独跑composer dump-autoload并观察耗时 - 根治：检查
opcache.enable_cli=1和apcu.enabled=1是否在 CLI 模式下生效（php -i | grep -E "(opcache|apcu)"）
