卡在Downloading https://时应调http-basic-timeout，它控制DNS解析、TLS握手、首字节等待及整个body传输；process-timeout则管理命令全生命周期，二者需协同配置。
直接调 process-timeout 和 http-basic-timeout，但只改一个基本没用——它们管的是完全不同的阶段。
卡在 Downloading https:// 时该调哪个参数
看到命令停在 Downloading https:// 并报 cURL error 28 或反复 retry，说明是单次 HTTP 请求卡在连接/首字节/传输阶段。这不是“下载慢”，而是底层请求被掐断了。
-
http-basic-timeout（Composer 2.2+）或旧版的http.timeout才是正解，它控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输，单位秒，默认仅 60（2.2+）或 300（旧版） - 别碰
config.timeout—— 它不生效，文档里都已废弃 - PHP 的
default_socket_timeout必须 ≥ 你设的http-basic-timeout，否则 PHP 自己先断连；查法：php -i | grep default_socket_timeout，常见值是 60，得同步改
为什么加了 timeout 还失败
因为 process-timeout 和 http-basic-timeout 是两道独立关卡，缺一不可：
-
process-timeout管整个命令生命周期：依赖解析、git clone、unzip、post-install-cmd 脚本执行……默认 300 秒，且 不能通过composer.json设置 -
http-basic-timeout只管每个 HTTP GET 请求，比如拉一个 100MB 的 dist ZIP 包，哪怕只剩最后 1KB 没传完，也会在这里超时 - Git 类包（
"type": "git"）会绕过镜像直连 GitHub，此时process-timeout才真正起作用——它会掐掉卡死的git clone进程
比调 timeout 更有效的三件事
单纯延长等待时间只是兜底，不是根治。国内用户 80% 的“超时”本质是源不稳定：
- 换阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，配完必须composer clear-cache，否则缓存可能已损坏 - 禁用 packagist.org 回源：镜像配置后，若仍见
packagist.org域名，说明回源未关，加"packagist.org": false到全局 config 的repositories里 - 中断后精准清理：
rm vendor/autoload.php && rm -rf vendor/composer/，再composer dump-autoload && composer install；别直接删整个vendor/，否则 autoload 丢失会引发连锁报错
真正麻烦的从来不是“等多久”，而是中断后 vendor/ 里那些校验失败却没被自动清除的包文件——它们静默存在，下次 install 时才爆 Failed to extract 或 Content-Length mismatch，这时候清缓存才是唯一出路。
