应修改 http-basic-timeout 参数，Composer 2.2+ 中该参数控制单次 HTTPS GET 全流程超时，默认仅60秒，弱网易超时，可执行 composer config -g http-basic-timeout 300 设为300秒。
Composer超时不是单个参数能解决的问题，必须同时处理 HTTP 请求层和子进程执行层，缺一不可——只调 process-timeout，卡在下载 ZIP 时照样失败；只调 http.timeout 或 http-basic-timeout，遇到 git clone 私仓或大包解压仍会中断。
卡在 Downloading https:// 该改哪个参数
这是 HTTPS 请求生命周期卡住，典型现象是反复 retry、报 cURL error 28 或 failed to open stream: Connection timed out。它只响应 HTTP 层超时配置，和 process-timeout 完全无关。
- Composer 2.2+ 推荐用
http-basic-timeout：它专管单次 HTTPS GET 的 DNS + TLS 握手 + 首字节 + body 传输总耗时，默认仅 60 秒（不是 300），弱网下极易击穿。运行composer config -g http-basic-timeout 300即可设为 5 分钟 - 旧版本（http.timeout：默认 300 秒，但注意它实际覆盖整个请求链路，包括 TLS 握手——很多用户误以为它不控握手，其实控，只是新版把它拆细了
- 务必检查 PHP 底层限制：
php -i | grep default_socket_timeout查出的值必须 ≥ 你设的 HTTP 超时值，常见默认是 60，若设了 300 却没同步调高，连接会在 60 秒被 PHP 提前掐断 - 临时覆盖优先级最高：
COMPOSER_HTTP_TIMEOUT=1200 composer install，适合 CI 调试
报 The process timed out 该调哪项
错误里明确含 [RuntimeException] The process "" exceeded the timeout，且加 -vvv 能看到最后执行的命令（如 git clone、unzip、post-install-cmd 脚本），这就是 process-timeout 在起作用。
-
process-timeout控制单个外部命令最大执行时间，默认 300 秒，和协议无关——HTTPS 下载、Git 克隆、解压、脚本执行全归它管 - 项目级固化：直接在
composer.json的config段写"process-timeout": 1800（整数，不带引号），提交后团队一致生效 - 全局生效：
composer config -g process-timeout 1800，写入~/.composer/config.json，适合本地开发或 CI 镜像预置 - 临时覆盖：
COMPOSER_PROCESS_TIMEOUT=1800 composer install或composer install --timeout=1800（注意等号不能少） - 设为
0表示禁用超时，不推荐长期使用——网络卡死时进程会无限挂起，无法 Ctrl+C 中断
为什么配了镜像还超时？代理配置必须成对出现
国内用户常忽略一点：Composer 对 HTTP 和 HTTPS 请求走两套完全独立的代理路由。所有包仓库（Packagist、GitHub、镜像源）都走 HTTPS，只配 http-proxy 会导致 HTTPS 请求静默 fallback 到直连，表现就是卡在 Loading composer repositories 或反复 cURL error 28。
- 必须同时配置：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890（注意：哪怕代理服务监听 HTTPS 端口，https-proxy的协议头也必须是http://） - 密码含
@或/必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword - 验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"，必须看到两行且格式合规 - NTLM 代理（如公司域环境）需中转：用
cntlm或px监听127.0.0.1:3128，再把 Composer 的两个 proxy 都指向它
最容易被忽略的底层干扰点
即使所有 Composer 配置都正确，超时仍可能发生——问题不在 Composer 本身，而在它依赖的 PHP 和系统层。
-
default_socket_timeout低于你设的 HTTP 超时：PHP CLI 的这个值会硬性掐断 socket 连接，查法php -i | grep default_socket_timeout，改法是调整php.ini中的default_socket_timeout，或启动时加php -d default_socket_timeout=600 - 镜像地址末尾多了一个
/：比如https://mirrors.aliyun.com/composer/（结尾斜杠），会导致 Composer 拼出错误 URL 如https://mirrors.aliyun.com/composer//packages.json，部分镜像服务器返回 404 或 503，看起来像超时 - 缓存未清导致元数据过期：运行
composer clear-cache再试，尤其在切换镜像或代理后 - 某些自建镜像不支持
Range请求：大 ZIP 包无法断点续传，一次传输失败就重来，反复 retry 看似超时，实为协议不兼容
