卡在Downloading https://时应调http-basic-timeout（Composer 2.2+），默认60秒太短，建议设300～600；同时必须同步调高PHP的default_socket_timeout，否则底层会提前中断连接。
直接改 process-timeout 和 http-basic-timeout 两个参数，缺一不可；只调一个大概率还是卡在 downloading 或 unzip 阶段。
卡在 Downloading https:// 时该调哪个 timeout
看 -vvv 输出最后一行：如果停在 Downloading https://...，说明是单次 HTTP 请求卡住，不是网速慢，而是 DNS、TLS 握手或首字节等待超时。这时候起作用的是 http-basic-timeout（Composer 2.2+），默认仅 60 秒，国内常见首字节延迟高，建议设为 300～600。
-
http.timeout在 Composer 2.x 中已弃用，不要用它替代http-basic-timeout -
process-timeout对此阶段完全无效——它不管 HTTP，只管git clone、unzip这类子进程 - 临时生效：
composer install --http-basic-timeout=300 - 永久生效：
composer config -g http-basic-timeout 300
The process timed out 错误必须调 process-timeout
错误信息里含 [RuntimeException] The process "" exceeded the timeout，加 -vvv 能看到最后执行的命令，比如 unzip -qq 或 git clone。这是子进程被杀，和 HTTP 完全无关。
-
process-timeout默认 300 秒，解压几百 MB 的 dist 包或拉大 Git 仓库很容易超 - 不推荐设为
0（不限时），万一远程仓库彻底不可达会无限挂起 - 全局设置：
composer config -g process-timeout 1800 - 项目级设置：在
composer.json顶层加"config": {"process-timeout": 1200} - CI 环境优先用环境变量：
COMPOSER_PROCESS_TIMEOUT=2000，某些版本更敏感
PHP 底层 socket 超时会提前掐断连接
即使你把 http-basic-timeout 设成 300，如果 PHP CLI 的 default_socket_timeout 是默认的 60 秒，cURL 在底层就会直接中断，Composer 根本收不到完整响应。
- 查当前值：
php -i | grep default_socket_timeout - 若低于你设的 timeout 值，必须同步调高，例如在
php.ini里设default_socket_timeout = 300 - 注意：Docker 或 CI 环境中，这个值可能被镜像覆盖，不能只信本地配置
- 不建议用
ini_set('default_socket_timeout', '300')—— Composer 启动后才加载，来不及
换镜像源比加 timeout 更治本
80% 的 “超时” 实质是源不稳定，不是网络差。阿里云镜像能绕过 DNS 污染、TLS 抖动和国外源响应延迟，但配置后必须清缓存，否则仍可能读取损坏的本地 ZIP。
- 全局配置：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否生效：
composer config -g repo.packagist应输出对应 URL - 必须清缓存：
composer clear-cache，否则残留坏包持续干扰 - 注意：
"type": "git"的包会绕过镜像直连 GitHub，此时要靠process-timeout+ Git 自身配置兜底 - 中断后别直接删整个
vendor/，精准清理：rm vendor/autoload.php && rm -rf vendor/composer/，再composer dump-autoload→composer install
真正麻烦的从来不是“等多久”，而是中断后 vendor/ 里那些看似完整、实则校验失败的包文件——它们不会自己消失，也不会被 -- 参数跳过。
