应调大 process-timeout 参数，它控制 git、unzip 等本地命令执行时限，默认 300 秒；可通过命令行（--process-timeout=1800）、项目 composer.json 或全局 config -g 设置，同时注意区分仅影响 HTTP 的 timeout 参数。

Composer install/update 时提示 ProcessTimedOutException 怎么办

这是 Composer 在执行某些耗时命令（比如 git clone、unzip 或脚本钩子）时，单个进程运行超过默认时限被强制终止导致的。根本原因不是网络慢，而是 process-timeout 值太小，尤其在低配机器、Docker 环境或含大量 post-install-cmd 脚本的项目中极易触发。

怎么改 process-timeout 参数

该参数控制单个外部进程允许的最大执行秒数，默认是 300（5 分钟）。可从三个层级调整，优先级由高到低：

• 命令行临时覆盖（推荐调试用）：

  composer install --process-timeout=1800

• 项目级配置（写入当前项目的 composer.json）：

  "config": {
    "process-timeout": 1800
  }

• 全局配置（影响所有项目，慎用）：

  composer config -g process-timeout 1800

注意：设为 0 表示禁用超时，但不建议生产环境使用，可能掩盖真正卡死的问题。

process-timeout 和 timeout 别搞混

Composer 还有另一个 timeout 配置（默认 300），它只控制 HTTP 请求的连接+响应总时间，和进程执行无关。两者常被误认：

• timeout：影响 packagist.org 元数据下载、zip 包拉取等网络操作
• process-timeout：影响 git、unzip、php scripts/xxx.php 等本地命令执行
• 同时超时？得两个参数都调大，比如：

  composer update --timeout=600 --process-timeout=1200

Docker 或 CI 环境下特别要注意的点

很多 CI（如 GitHub Actions、GitLab CI）或 Docker 容器默认资源受限，即使调大 process-timeout，仍可能因内存不足或 CPU 节流导致进程假死。这时单纯加时间没用：

• 确认容器内存是否充足（docker stats 查看）
• 避免在 post-install-cmd 中执行重操作（如生成缓存、构建前端）——这些应拆到单独步骤
• CI 中可加 --no-scripts 跳过脚本，后续再手动运行
• 某些 Git 源（如私有 GitLab）若启用了慢速 SSH 认证，也容易卡在 git clone，此时需配合 git config --global core.sshCommand 优化

超时本质是“等待结果太久”，而不是“一定出错”。调参只是让 Composer 多等一会儿，真卡死或资源不够时，得查进程本身在干什么。