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类仓库（vcstype）时，每次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 请求都少走几公里。 
