The process timed out错误源于git clone等本地子进程卡死，非网络问题；应设process-timeout（如1800秒）而非http-timeout，CI中优先用COMPOSER_PROCESS_TIMEOUT环境变量，避免设0掩盖SSH失败、内存不足等真实问题。
Composer 报 The process timed out，不是网络慢，而是它启动的某个子进程（比如 git clone、unzip 或 post-install-cmd 脚本）真正在本地卡死了。调高 process-timeout 是直接解法，但必须知道在哪设、设多少、以及为什么设错反而更难排查。
为什么 --timeout=0 不是万能解药
加 --timeout=0 确实能禁用超时检查，但副作用明显：
-
--timeout=0只影响当前命令，不覆盖插件或自定义 installer 启动的子进程（比如某些私有包用 SVN + 自定义脚本） - 一旦遇到 DNS 解析失败、SSH 密钥缺失、或镜像源彻底不可达，Composer 会无限 hang 住，CI 流水线可能卡数小时
- PHP 层的
max_execution_time或容器memory_limit仍会触发强制终止，此时你看到的仍是“超时”，但根本原因已不同
process-timeout 和 http-timeout 必须分清
这两个参数控制完全不同的环节，改错一个就白忙：
-
process-timeout：管git、unzip、php scripts/build.php这类本地命令，单位秒，默认 300；超时后报The process timed out -
http-timeout：管file_get_contents()或 cURL 拉取packages.json、ZIP 包等 HTTP 请求，默认也是 300；超时后常见错误是Connection timed out或curl error 28 - 若同时卡在下载和安装阶段，得两个都调：
COMPOSER_HTTP_TIMEOUT=600 COMPOSER_PROCESS_TIMEOUT=1200 composer install
CI/CD 中最稳的配置方式
Docker 容器或 GitHub Actions 每次都是干净环境，不能依赖全局 config，推荐显式传参+环境变量组合：
- 开头设置环境变量（覆盖所有子进程，包括插件）：
export COMPOSER_PROCESS_TIMEOUT=1800（Linux/macOS）或$env:COMPOSER_PROCESS_TIMEOUT=1800（PowerShell） - 执行命令时加
--no-interaction --no-progress --process-timeout=1800，避免交互阻塞和进度条干扰 - 跳过耗时脚本先验证依赖：
composer install --no-scripts --no-plugins，确认是否真卡在post-install-cmd - 别用
composer update上 CI，始终基于已提交的composer.lock执行install
设多大才合理，而不是越大越好
process-timeout 超过 7200 秒（2 小时）会被 Composer 硬编码忽略，强制回退到 300 秒——这是白设。真正该关注的是：
- 本地开发：设
3000（50 分钟）足够，再大说明该查镜像源或网络了 - CI 构建：设
1800（30 分钟），配合日志监控（-v参数），方便定位卡在哪一步 - 如果每次都在接近超时值时中断（比如总卡在 1790 秒），大概率是 GitHub API 限流、私有 GitLab 响应慢，或
post-install-cmd里调用了未安装的全局命令（如php-cs-fixer）
超时本身只是表象，关键要看出现在哪一层：是网络连不上、Git 认证失败、解压工具缺失，还是脚本逻辑写死。盲目拉长 timeout，只会把问题拖得更隐蔽。
