Composer 无长连接机制，超时问题90%源于Git层；有效策略是降并发、切国内镜像源、单独配置Git超时，而非调整HTTP超时参数。
Composer 本身不维护长连接，所谓“配置长连接防超时”是个误解——它每次 HTTP 请求都新建 curl 句柄，用完即弃；你调 http.timeout 或 http.connect_timeout 只影响元数据拉取，对 git clone 完全无效。
为什么 Composer 没有真正的长连接池
Composer 的 HTTP 客户端基于 cURL，但所有请求都是短连接（--no-keepalive 默认启用），不复用 TCP 连接。它甚至不保留句柄供后续复用，更谈不上“连接池”或“长连接保活”。你看到的“卡在 Cloning into”或“Operation timed out”，90% 是 Git 层行为，和 Composer 配置无关。
常见错误现象：
-
cURL error 28卡在* Trying x.x.x.x:443→ DNS 或网络通路问题，不是超时设置太小 -
Cloning into 'xxx'卡住 → Composer 已交出控制权给git，此时http.timeout完全失效 -
ulimit -Sn持续上涨、/proc/pid/fd/数量破千 → 并发下载失控导致 fd 泄露，不是连接没释放，是根本没走到 fclose
真正有效的生产环境防超时组合策略
别碰“长连接”，盯住三个真实可控点：并发数、镜像源、Git 行为。
- 强制降并发：
composer config -g repos.packagist.org.concurrent-downloads 2（注意键名是repos.packagist.org，不是http-max-concurrent-downloads） - 锁定国内镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（结尾/不能少） - 清缓存再重试：
composer clear-cache && composer update --refresh（--refresh要求 Composer ≥2.5） - 若包走 Git（查
composer show vendor/package --all | grep -A5 source），需单独调 Git 超时：git config --global core.sshCommand "ssh -o ConnectTimeout=30 -o ServerAliveInterval=30"
哪些配置纯属误导，别浪费时间
以下操作对生产环境防超时基本无效，还可能掩盖真实问题：
- 设
composer config -g http.timeout 600：只管packages.json下载，不管git clone或 zip 解压 - 改
process-timeout：仅控制单个外部命令（如 git）总耗时，不解决卡在握手或 DNS 的根因 - 加
COMPOSER_IPRESOLVE=4后又连不上 IPv6 镜像：直接触发CURL_ERROR 7，且不进重试逻辑 - 在代理环境只配
HTTP_PROXY不配HTTPS_PROXY：Composer 默认全走 HTTPS，直连失败后不重试
最易被忽略的是：你看到的“超时”，往往根本不是时间到了，而是连接压根没建起来。先用 curl -v https://mirrors.aliyun.com/composer/packages.json 和 nslookup mirrors.aliyun.com 确认通路，再动配置。否则所有 timeout 调整都是在修错地方的水管。
