Composer install/update 触发 ProcessTimedOutException 的本质是 PHP proc_open() 子进程被强制终止，由 Composer 自身的 process-timeout 配置（默认300秒）控制，常见于网络慢、镜像未切、依赖复杂或内存不足等场景。
为什么 Composer install/update 会触发 ProcessTimedOutException
这个异常本质是 PHP 的
子进程被强制终止，不是 Composer 自身逻辑错误。默认超时由
配置控制（单位秒），而非系统级 timeout 命令。常见于网络慢、镜像未切、依赖树复杂或 PHP 进程被资源限制（如 Docker 容器内存不足）的场景。
默认值为
（5 分钟），但某些大型项目（如 Laravel + 多个私有包 +
git
sources）在低带宽下很容易突破
PHP 的
不影响子进程，只管当前脚本；真正起作用的是 Composer 自己的超时机制
使用
类仓库（
type）时，每次
或
都计入总超时，而非单次
如何临时绕过超时（开发/CI 场景）
最直接方式是用命令行参数覆盖配置，无需改
或全局设置。注意：仅推荐在可控环境（如 CI 流水线、本地调试）中使用，不建议长期写死在脚本里。
设为 0 表示禁用超时：
设为更大值（例如 20 分钟）：
若在 Docker 中执行，还需确认容器未被
或
包裹 —— 那是另一层中断，Composer 看不到
如何永久调整并避免反复踩坑
优先通过 Composer
配置文件
管理，比每次加参数更可靠。注意区分全局配置和项目级配置的作用范围。
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
全局生效（影响所有项目）：
仅当前项目生效（写入
）：
配置后可验证：
（无输出表示使用默认值）
若已设为
但仍失败，大概率是内存不足 —— 检查
是否足够（建议 ≥ 1.5G），尤其在
时解析锁文件阶段
比调超时更有效的优化手段
延长超时只是兜底，真正提速要从源头减少耗时环节。以下操作通常比单纯加 timeout 更立竿见影。
切国内
镜像源
：
（或阿里、
腾讯
等维护的镜像）
禁用 packagist.org 兜底（防止 fallback 拖慢）：
跳过 autoload 生成（安装后手动运行）：
，再
对私有包，确认是否用了
而非
方式 ——
可大幅缩短下载时间
超时本身不是问题，而是信号——它在提醒你网络、配置或依赖结构存在瓶颈。改 timeout 是最快的止痛药，但真正省时间的，是让每个
和
请求都少走几公里。
proc_open()process-timeout300max_execution_timegitvcsgit clonegit checkoutcomposer.jsoncomposer install --process-timeout=0composer update --process-timeout=1200docker run --stop-timeouttimeoutcomposer config -g process-timeout 1200composer.jsoncomposer config process-timeout 1200composer config process-timeout0memory_limitupdatecomposer config -g repo.packagist composer https://packagist.phpcomposer.comcomposer config -g repo.packagist falsecomposer install --no-autoloadercomposer dump-autoload --optimizegitdist"preferred-install": {"my-vendor/*": "dist"}
{
"config": {
"process-timeout": 1200,
"preferred-install": {
"my-vendor/*": "dist"
}
}
}
git clonecurl