解决Composer执行时间过长导致的ProcessTimedOutException错误

composer install/update 触发 ProcessTimedOutException 的本质是 php proc_open() 子进程被强制终止，由 Composer 自身的 process-timeout 配置（默认300秒）控制，常见于网络慢、镜像未切、依赖复杂或内存不足等场景。

为什么 Composer install/update 会触发 ProcessTimedOutException

这个异常本质是 PHP 的 proc_open() 子进程被强制终止，不是 Composer 自身逻辑错误。默认超时由 process-timeout 配置控制（单位秒），而非系统级 timeout 命令。常见于网络慢、镜像未切、依赖树复杂或 PHP 进程被资源限制（如 docker 容器内存不足）的场景。

• 默认值为 300（5 分钟），但某些大型项目（如 laravel + 多个私有包 + git sources）在低带宽下很容易突破
• PHP 的 max_execution_time 不影响子进程，只管当前脚本；真正起作用的是 Composer 自己的超时机制
• 使用 git 类仓库（vcs type）时，每次 git clone 或 git checkout 都计入总超时，而非单次

如何临时绕过超时（开发/CI 场景）

最直接方式是用命令行参数覆盖配置，无需改 composer.json 或全局设置。注意：仅推荐在可控环境（如 CI 流水线、本地调试）中使用，不建议长期写死在脚本里。

• 设为 0 表示禁用超时：composer install --process-timeout=0
• 设为更大值（例如 20 分钟）：composer update --process-timeout=1200
• 若在 Docker 中执行，还需确认容器未被 docker run --stop-timeout 或 timeout 包裹 —— 那是另一层中断，Composer 看不到

如何永久调整并避免反复踩坑

优先通过 Composer 配置文件管理，比每次加参数更可靠。注意区分全局配置和项目级配置的作用范围。

• 全局生效（影响所有项目）：composer config -g process-timeout 1200
• 仅当前项目生效（写入 composer.json）：composer config process-timeout 1200
• 配置后可验证：composer config process-timeout（无输出表示使用默认值）
• 若已设为 0 但仍失败，大概率是内存不足 —— 检查 memory_limit 是否足够（建议 ≥ 1.5G），尤其在 update 时解析锁文件阶段

比调超时更有效的优化手段

延长超时只是兜底，真正提速要从源头减少耗时环节。以下操作通常比单纯加 timeout 更立竿见影。

• 切国内镜像源：composer config -g repo.packagist composer https://packagist.phpcomposer.com（或阿里、腾讯等维护的镜像）
• 禁用 packagist.org 兜底（防止 fallback 拖慢）：composer config -g repo.packagist false
• 跳过 autoload 生成（安装后手动运行）：composer install --no-autoloader，再 composer dump-autoload --optimize
• 对私有包，确认是否用了 git 而非 dist 方式 —— "preferred-install": {"my-vendor/*": "dist"} 可大幅缩短下载时间

{     "config": {         "process-timeout": 1200,         "preferred-install": {             "my-vendor/*": "dist"         }     } }

超时本身不是问题，而是信号——它在提醒你网络、配置或依赖结构存在瓶颈。改 timeout 是最快的止痛药，但真正省时间的，是让每个 git clone 和 curl 请求都少走几公里。