直接调高process-timeout和http-basic-timeout并更换阿里云镜像源三者缺一不可；卡在Downloading https://时应调http-basic-timeout，卡在Executing command时才调process-timeout；换镜像比加timeout更治本，因80%超时源于源不稳定。
直接调高 process-timeout 和 http-basic-timeout，再换阿里云镜像源，三者缺一不可。只改一个参数大概率还是卡住。
卡在 Downloading https:// 时该调哪个 timeout
看 -vvv 输出最后一行，如果停在 Downloading https://，说明是单次 HTTP 请求卡死——不是下载慢，而是 DNS 解析、TLS 握手或首字节等待就失败了。
-
http-basic-timeout（Composer 2.2+）或旧版的http.timeout才管这个，控制单次请求总耗时，默认仅 60 秒，国内常见首字节延迟高，建议设为300～600 -
process-timeout完全不参与这一阶段，它只管后续解压、脚本执行等子进程 - 临时生效：
composer install --http-basic-timeout=300；永久生效：composer config -g http-basic-timeout 300
The process timed out 错误该调哪一项
错误里明确带 [RuntimeException] The process "" exceeded the timeout，且 -vvv 最后一行是 Executing command，比如 git clone 或 unzip，这就是 process-timeout 在起作用。
- 它控制每个外部命令（含
git、unzip、php artisan）的最大执行时间，默认 300 秒，和 HTTP 完全无关 - 设为
0表示不限时，但不推荐——万一 Git 仓库彻底不可达，会无限挂起 - 全局改：
composer config -g process-timeout 1800；CI 中更稳：COMPOSER_PROCESS_TIMEOUT=2000
为什么换镜像比加 timeout 更治本
80% 的“超时”本质是源不稳定：DNS 污染、TLS 握手抖动、国外源响应延迟高，不是你网速慢。阿里云镜像能绕过这些链路问题。
- 配置命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 配完必须清缓存：
composer clear-cache，否则仍可能读取损坏的本地缓存 - 验证是否生效：
composer config -g repo.packagist应输出对应 URL，且composer install --dry-run中的下载链接要变成mirrors.aliyun.com - 注意：
"type": "git"的包会直连 GitHub，此时必须靠process-timeout+ Git 自身超时兜底
中断后重试前必须清理什么
Composer 没有断点续传。中断后残留的破损 ZIP、截断的 installed.json 或卡死的临时目录，会持续干扰后续执行。
- 不要直接删整个
vendor/——这会导致autoload.php缺失，后续命令直接报错 - 精准清理：
rm vendor/autoload.php+rm -rf vendor/composer/，再运行composer dump-autoload→composer install - 若仍报
Failed to extract或Content-Length mismatch，说明缓存已坏，必须composer clear-cache
真正麻烦的从来不是“等多久”，而是中断后 vendor/ 里那些看似完整、实则校验失败的包文件——它们不会自己消失，也不会被 -- 参数跳过。
