卡在Resolving dependencies是DNS解析慢或元数据拉取问题，非HTTP超时；需先dig验证DNS、换DNS（如114.114.114.114）、配镜像源并清缓存，同时设置http-basic-timeout和process-timeout双参数。
卡在 Resolving dependencies 是 DNS 或元数据拉取慢，不是 HTTP 超时
看到终端停在 Resolving dependencies 且几秒不动，说明 Composer 正在查 Packagist 的 provider 列表（比如 p2/monolog/monolog.json），这阶段不走 HTTP 下载逻辑，也不受 http-basic-timeout 控制。本质是 DNS 解析慢、TLS 握手抖动或源响应延迟——尤其在国内直连 packagist.org 时常见。
- 先验证是否 DNS 问题：
dig packagist.org +short看响应是否超 500ms；若超时或无返回，换 DNS（如114.114.114.114或223.5.5.5） - 临时绕过：加
--repository=https://mirrors.aliyun.com/composer/强制走镜像，不依赖全局配置 - 永久生效必须清缓存：
composer clear-cache，否则仍可能读本地失效的 provider 缓存 - 检查项目级
composer.json是否硬写了"repositories"—— 它会屏蔽全局镜像，导致元数据仍走官方源
设置 http-basic-timeout 对元数据拉取无效，但必须配对 process-timeout
http-basic-timeout 只控制单次 HTTP 请求（如下载 ZIP 包、GET 元数据 JSON 文件），默认 60 秒。但 Resolving dependencies 阶段往往要并发拉几十个 p2/*.json，每个都卡在首字节等待，http-basic-timeout 确实能缓解，但它不能解决并发请求堆积导致的总耗时溢出。
-
process-timeout才是关键：它管整个命令生命周期，默认 300 秒。元数据解析慢+并发请求多，很容易突破这个阈值 - 必须同时设两个参数：
composer config -g http-basic-timeout 300+composer config -g process-timeout 1200 - 只调
http-basic-timeout不改process-timeout，依然会在 5 分钟后报The process timed out - CI 环境建议用环境变量：
COMPOSER_PROCESS_TIMEOUT=1200，避免配置未继承
镜像源没生效？重点查 packagist.org 回源和配置层级
很多用户配了阿里云镜像却仍卡在 Resolving dependencies，实际日志末行是 Downloading https://repo.packagist.org/p2/... —— 这说明镜像根本没生效，Composer 在 fallback 回官方源。
- 验证是否真生效：
composer config -g repo.packagist应输出{"type":"composer","url":"https://mirrors.aliyun.com/composer/"} - 项目级
composer.json若含"repositories"字段，且没显式禁用官方源，Composer 会先查镜像，再回源补全缺失 provider，造成双重请求 - 正确写法是在
composer.json顶层加："packagist.org": false（注意不是在repositories里），彻底关闭回源 - K8s 或 Docker 构建中，
composer config -g无效，必须下沉到composer.json或用--repository参数
真正麻烦的是残留的坏缓存和 vendor 状态
中断一次 composer install 后，vendor/composer/installed.json 可能写了一半，composer.lock 与实际 vendor 不一致，后续再跑会静默跳过元数据拉取，直接卡在 autoload 生成或报校验失败。
- 不要直接删整个
vendor/——autoload.php缺失会导致后续命令无法初始化 Composer 自身 - 精准清理：
rm -f vendor/autoload.php && rm -rf vendor/composer/，再composer dump-autoload恢复基础结构 - 若仍报
Content-Length mismatch或Failed to extract，说明缓存已损坏，必须composer clear-cache - WSL2 用户额外注意：
Generating autoload files卡住大概率是 symlink 解析慢，不是元数据问题
