卡在Downloading https://时应调http-basic-timeout而非process-timeout，因该场景属单次HTTP请求卡住，需设为300秒以上并确保PHP default_socket_timeout不低于此值。
直接改 process-timeout 和 http-basic-timeout，缺一不可；只调一个大概率还是失败。
卡在 Downloading https:// 该调哪个参数
看 -vvv 输出最后一行：如果停在 Downloading https://，说明是单次 HTTP 请求卡住，不是整体流程慢。这时候 process-timeout 完全不生效，必须调 http-basic-timeout（Composer 2.2+）或旧版的 http.timeout。
-
http-basic-timeout控制单次 GET 的连接 + 首字节等待 + 读取头几 KB，单位秒，默认仅 60，国内 DNS/TLS 握手慢时极易触发 - 设为
300是较稳起点，600更保险，但不能高于 PHP 的default_socket_timeout - 项目级写法：
composer config http-basic-timeout 300（写入当前composer.json的config段） - 全局写法：
composer config -g http-basic-timeout 300
The process timed out 错误该调哪一项
错误里明确含 [RuntimeException] The process "" exceeded the timeout，且 -vvv 最后一行是 unzip、git clone 或 tar -xzf，这就是 process-timeout 在起作用。
- 它和网络无关，只管子进程执行时长，默认 300 秒，解压几百 MB 的 dist 包很容易超
- 设为
1800（30 分钟）比较稳妥，调试时可先试600确认是否走通 - 临时覆盖优先级最高：
COMPOSER_PROCESS_TIMEOUT=1800 composer install - 注意：
process-timeout不能通过composer.json的config.timeout设置——这个 key 已废弃多年，写了也无效
为什么换镜像比加 timeout 更治本
80% 的 “超时” 实际是源不稳定导致的握手失败、DNS 污染或 TLS 抖动，不是网速问题。阿里云镜像能绕过这些环节，效果远超单纯拉长时间。
- 配置命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 配完必须清缓存：
composer clear-cache，否则仍可能读损坏的本地 ZIP - 验证是否生效：
composer config -g repo.packagist应输出对应 URL，且composer install --dry-run中下载链接要变成mirrors.aliyun.com - Git 类包（
"type": "git"）会绕过镜像直连 GitHub，此时必须靠process-timeout+ Git 自身超时（如git config --global core.sshCommand "timeout 300 ssh"）兜底
中断后重试前必须清理什么
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 - PHP 底层
default_socket_timeout必须 ≥ 你设的http-basic-timeout，否则 cURL 会在底层提前掐断，查法：php -i | grep default_socket_timeout
真正麻烦的从来不是“等多久”，而是中断后 vendor/ 里那些看似完整、实则校验失败的包文件——它们不会自己消失，也不会被 -- 参数跳过。
