process-timeout是Composer控制子进程（如git clone、unzip）最大执行时间的配置项，单位秒，默认300，与HTTP超时无关；错误含“[RuntimeException] The process ... exceeded the timeout”即为此项触发。
process-timeout 是什么，为什么它不是 http.timeout
process-timeout 控制的是 Composer 启动的子进程（比如 git clone、unzip、php artisan 脚本）的最大执行时间，单位秒，默认 300。它和网络下载无关，所以调 http.timeout 解决不了 The process timed out 错误。错误信息里只要出现 [RuntimeException] The process "" exceeded the timeout，就一定是 process-timeout 在起作用。
三种设置方式优先级和实操要点
命令行参数 > 项目级配置 > 全局配置。临时调试建议用命令行，长期项目推荐写进 composer.json。
- 临时单次生效（最高优先级）：
COMPOSER_PROCESS_TIMEOUT=1200 composer install或composer install --timeout=1200（注意是--timeout，不是--process-timeout） - 项目级生效（推荐，可提交、可复现）：
composer config process-timeout 1800，会写入当前composer.json的config段 - 全局生效（影响所有项目）：
composer config -g process-timeout 1200，修改的是~/.composer/config.json
设为 0 表示禁用超时，但可能掩盖死锁或挂起问题，不建议在 CI 中长期使用。
常见踩坑：光调 process-timeout 不管用
即使把 process-timeout 设到 3600，仍报超时，大概率是其他瓶颈在“抢跑”：
-
memory_limit不足：Composer update 解析依赖树阶段很吃内存，建议 CLI 模式下设为-1或 ≥ 1.5G，用php -d memory_limit=-1 composer update验证 - 磁盘空间或 inodes 耗尽：尤其
vendor/下有大量 symlink 或嵌套包时，unzip可能因fork failed直接退出，错误里常带proc_open(): fork failed - Cannot allocate memory - Docker 容器被外部
--stop-timeout或timeout命令包裹：Composer 看不到这层中断，只会显示超时 - post-install-cmd 脚本本身卡住：比如
php artisan config:cache因配置错误无限循环，这时加 timeout 只是延长失败时间
配合镜像源和禁用 autoload 才算完整防断开
单纯拉长 process-timeout 是兜底，不是提速。真正减少超时概率要组合操作：
- 换国内镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 禁用并行下载（降低并发压力）：
composer config -g disable-tls false（部分旧版需配use-include-path false） - 安装时不生成 autoload：
composer install --no-autoloader，装完再手动composer dump-autoload --optimize - CI 环境务必显式传
COMPOSER_PROCESS_TIMEOUT和COMPOSER_HOME，否则容器重启后配置丢失
最易被忽略的是 PHP 底层 default_socket_timeout —— 它若低于你设的 http.timeout，cURL 会在更早阶段掐断连接，而这个值和 process-timeout 完全无关，但常一起失效。
