Composer的process-timeout控制git clone、unzip等子进程单次执行时长，默认300秒，需用composer config -g process-timeout 1800全局设置；http.timeout才控制HTTP下载总耗时，二者不可混淆。
全局设置 process-timeout 控制子进程超时
Composer 的 process-timeout 管的是 git clone、unzip、post-install-cmd 这类外部命令的单次执行时长，不是网络下载时间。默认 300 秒，弱网或大包下极易触发 [RuntimeException] The process "" exceeded the timeout。
全局生效最稳的方式是：
-
composer config -g process-timeout 1800（写入~/.composer/config.json） - 手动编辑
~/.composer/config.json，在"config"段里加"process-timeout": 1800 - CI/CD 中推荐用环境变量兜底：
COMPOSER_PROCESS_TIMEOUT=2000，它优先级最高且不依赖配置文件存在
注意：process-timeout=0 表示禁用超时，但别长期用——万一 git 仓库不可达或解压卡死，命令会无限挂起。
全局设置 http.timeout 控制 HTTP 下载总耗时
当卡在 Downloading https://... 或报 cURL error 28，说明是 HTTP 层超时，这时候改 process-timeout 完全无效，必须调 http.timeout。
这个值控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 ZIP 包传输的**总时间**，默认仅 300 秒：
-
composer config -g http.timeout 600（推荐设为 600～1200） - 若要临时覆盖，用
COMPOSER_HTTP_TIMEOUT=1200 composer install - 项目级更可控：运行
composer config http.timeout 600，写入当前composer.json的config段
⚠️ 关键陷阱：PHP CLI 的 default_socket_timeout 必须 ≥ 你设的 http.timeout，否则底层 socket 会在 60 秒直接断连，Composer 根本收不到你的配置。查法：php -i | grep default_socket_timeout，不够就改 php.ini 里的 default_socket_timeout = 1200。
为什么只设 --timeout 参数经常没用
composer install --timeout=1200 看似简单，但有硬限制：
- 它只覆盖
process-timeout，对 HTTP 下载阶段无效 - 少等号（
--timeout 1200）会被静默忽略，必须带= - Composer 2.2+ 才支持
--http-basic-timeout单独调 HTTP 超时，旧版本不行 - 某些 CI 环境（如 GitHub Actions）里，runner 自身的 PHP 配置可能覆盖掉该参数，不如环境变量可靠
真正卡住时，先看错误信息里有没有 cURL error 28（HTTP 层）还是 The process "" exceeded the timeout（子进程层），再决定动哪个参数。
国内用户绕不开的镜像和内存问题
光调 timeout 不解决根本问题：
- 不切镜像源，
--timeout=3600也连不上packagist.org；务必先跑：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 内存不足会导致
composer update在解析锁文件阶段 OOM，表现和超时一模一样；确认memory_limit≥ 1.5G，CLI 下可临时加php -d memory_limit=2G /usr/bin/composer update - 用了
"type": "vcs"的包，每次git clone都单独计时，且受 SSH/代理影响；建议先手动git clone测试是否真卡在网络环节
timeout 是熔断开关，不是加速器。真正慢的根源往往在镜像、DNS、内存或 Git 配置，别一上来就拉高阈值。
