应调大 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 多等一会儿，真卡死或资源不够时，得查进程本身在干什么。
