卡在Downloading https://时应调http.timeout参数，该参数控制DNS解析、TLS握手、首字节等待及整个body传输总时间，默认300秒，弱网易超时，须同步调高PHP的default_socket_timeout。
直接结论：卡在 Downloading https:// 时，http.timeout 是第一要调的参数；但只调它不够，必须同步检查 php.ini 中的 default_socket_timeout，否则 PHP 层会提前掐断连接。
卡在 Downloading https:// 该调哪个参数
这是 HTTP 请求阶段卡住，比如拉 packages.json、下载 ZIP 包，错误里常带 cURL error 28 或反复 retry 后失败。它不看 process-timeout，只认 http.timeout（Composer 2.x）。
http.timeout 控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输的总时间，单位秒，默认仅 300（5 分钟），弱网下极易触发。
- 项目级最稳：运行
composer config http.timeout 600，写入当前composer.json的config段，可提交、可复现 - 全局生效：用
composer config -g http.timeout 600，写入~/.composer/config.json - 临时覆盖优先级最高：
COMPOSER_HTTP_TIMEOUT=1200 composer install，适合 CI 调试
为什么调了 http.timeout 还超时
常见原因是 PHP 自身的 socket 超时比 Composer 设的还短——php -i | grep default_socket_timeout 查出的值若低于你设的 http.timeout，连接会在 PHP 层被强制中断。
默认值常为 60 秒，远低于 Composer 的 300 秒，结果就是：Composer 还没开始等，PHP 已经把连接关了。
- 查当前值：
php -i | grep default_socket_timeout - 改
php.ini（CLI 模式）：default_socket_timeout = 1200 - 验证是否生效：
php -r "echo ini_get('default_socket_timeout');"
process-timeout 和 http.timeout 到底谁管什么
这两个参数完全独立，混用等于蒙眼调参：
-
http.timeout：单次 HTTP 请求生命周期（如 GET 一个 ZIP 包），建议设 300～600 -
process-timeout：整个composer install命令从开始到结束的总耗时上限（含解压、运行脚本、生成 autoloader），默认 300，大项目建议设 1200 -
http-basic-timeout（Composer 2.2+）：控制单次 HTTP 连接/读取时限，和http.timeout不同，它不包含 DNS/TLS 时间，只管“连上后等数据”，默认 60，可设 240
注意：config.timeout 是 v1 废弃项，v2 完全不读；http-basic.timeout 拼错少个 - 也无效。
换镜像后仍卡 Downloading？别只盯着 timeout
阿里云镜像虽快，但对 "type": "git" 的包（如 dev-master）无效——Composer 会绕过镜像直连 GitHub，此时真正瓶颈是 git clone 本身。
- 确认是否真走镜像：
composer install -vvv看最后一行 URL 是否含mirrors.aliyun.com - 如果是
git@github.com:或https://github.com/，说明走的是 Git 协议，需额外配 Git 超时：git config --global http.postBuffer 524288000、git config --global http.lowSpeedLimit 0 - CI 环境中，镜像配置不会自动继承，必须在 workflow 中显式执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
真正容易被忽略的是：缓存损坏、OpenSSL 扩展未启用、或 composer clear-cache 没跑——这些都会让 Composer 反复重试同一个失败的下载，而不是换路径重来。
