最省事方案是用环境变量COMPOSER_PROCESS_TIMEOUT和COMPOSER_HTTP_TIMEOUT覆盖，二者分阶段生效：前者控制解压及脚本执行，后者控制HTTP下载；国内弱网需同步调高并换阿里云镜像源。
直接用环境变量覆盖，优先级最高
临时救急或 CI/CD 场景下，COMPOSER_PROCESS_TIMEOUT 和 COMPOSER_HTTP_TIMEOUT 是最省事的方案——它们不依赖配置文件、不需改项目、不涉及权限问题，且优先级高于所有 config 设置。
常见组合：
-
COMPOSER_PROCESS_TIMEOUT=1800：控制git clone、unzip、post-install-cmd等子进程，设为 1800（30 分钟）较稳妥 -
COMPOSER_HTTP_TIMEOUT=1200：控制 HTTPS 全周期（DNS + TLS + body 下载），弱网拉大 ZIP 包必须同步调高 -
COMPOSER_HTTP_BASIC_TIMEOUT=300：Composer 2.2+ 才支持，细粒度管单次 GET 连接/读取，防握手慢中断
执行时直接拼接：
COMPOSER_PROCESS_TIMEOUT=1800 COMPOSER_HTTP_TIMEOUT=1200 composer install
注意：COMPOSER_HTTP_TIMEOUT 在某些旧版 Composer 中可能被忽略，建议搭配 php -i | grep default_socket_timeout 检查 PHP 底层是否也设为 ≥1200，否则 cURL 会在底层提前断连。
别只调 process-timeout，http.timeout 必须同步改
卡在 Downloading https:// 阶段（比如拉 packages.json 或 ZIP 包头）时，process-timeout 完全无效——它只管子进程，不管 HTTP 请求本身。真正起作用的是 http.timeout。
但光改 http.timeout 也不够：一旦 ZIP 下载完成，紧接着的 unzip 或 tar -xzf 可能因包体积大而超时，这时才轮到 process-timeout 发挥作用。
所以这两个参数是分阶段生效的：
-
http.timeout：决定“能不能把 ZIP 文件完整拉下来” -
process-timeout：决定“拉下来后能不能解压完、能不能跑完 post-install 脚本”
默认都是 300 秒，国内弱网下基本必挂。推荐起步值：两者都设为 1200 或更高，再按实际表现微调。
全局配置比每次敲命令更可靠
开发机或 CI runner 上频繁执行 composer install，靠环境变量容易漏写或拼错。直接写进全局配置一劳永逸：
composer config -g process-timeout 1800<br>composer config -g http-basic-timeout 300
注意：http.timeout 无法通过 composer config -g 设置（Composer 不支持），只能靠环境变量或项目级 composer.json 的 config 段写入；而 process-timeout 和 http-basic-timeout 两者都支持 -g。
验证是否生效：
composer config process-timeout<br>composer config -g http-basic-timeout
有输出即表示已设置；无输出说明还在用默认值。
换镜像源比加 timeout 更治本
很多“timeout”本质不是时间不够，而是根本连不上 packagist.org。哪怕你设了 --timeout=3600，如果 DNS 解析失败或 TLS 握手卡住，照样报 cURL error 28。
国内用户应优先执行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/-
composer config -g repo.packagist false（禁用官方源 fallback，避免兜底重试拖慢流程）
这两步做完，多数场景下 process-timeout=600 就足够，不用硬顶到 1800。真正卡住的，往往不是超时，而是没切源、没关 fallback、或者 PHP 底层 socket 超时（default_socket_timeout）比 Composer 设的还小。
