Composer 默认 process-timeout 为 300 秒，可通过 composer config -g process-timeout 1800 全局设为 1800 秒；配置优先级为命令行 > 项目 composer.json > 全局 config.json > 默认值，需检查是否被覆盖，并结合 timeout、github-oauth 等配置综合排查超时原因。
Composer 安装超时默认是 300 秒（5 分钟），遇到大包、慢源或网络抖动时经常报 proc_open(): fork failed 或直接卡在 Installing dependencies 阶段。这不是 PHP 配置问题，而是 Composer 自身的 process-timeout 限制，必须通过配置修改。
用 composer config 设置全局超时值
全局配置写入 ~/.composer/config.json（Linux/macOS）或 %APPDATA%\Composer\config.json（Windows），执行命令即可：
composer config -g process-timeout 1800
这会把超时设为 1800 秒（30 分钟）。注意几点：
-
-g表示 global，不加则只影响当前项目composer.json - 值必须是整数，单位是秒；设为
0表示禁用超时（不推荐，可能无限挂起） - 该配置控制的是所有子进程（如
git clone、unzip、php install-scripts）的单次执行上限，不是整个install命令总耗时 - 如果已存在本地
composer.json中的config.process-timeout，它会优先于全局配置
为什么改了还是超时？检查配置生效顺序
Composer 配置有明确优先级：命令行参数 > 项目 composer.json > 全局 config.json > 默认值。常见失效场景：
Phy Git Blame Archaeologist
下载
Git 历史考古工具，回答“为什么这段代码存在？”，适用于任意文件、行或可疑代码块。链式调用 git blame → git log --follow → commit 信息...
- 项目根目录下
composer.json包含"config": {"process-timeout": 60}—— 这会覆盖全局设置 - 运行时显式传了
--process-timeout=300，会覆盖所有配置文件 - 使用
COMPOSER_PROCESS_TIMEOUT环境变量，它比配置文件优先级更高
验证当前生效值，运行：
composer config process-timeout
不加 -g 会显示项目级值；加 -g 显示全局值；若输出为空，说明该层级未设置，将回退到上一级或默认值。
超时相关联的其他关键配置
process-timeout 只管子进程，但实际卡顿还常和以下配置有关：
-
timeout：HTTP 请求超时（如访问 Packagist），单位秒，默认 300，通过composer config -g timeout 600调整 -
github-oauth：没配 GitHub Token 时，API 限流会导致下载极慢甚至失败，超时前就已卡住 -
fxp-asset-plugin已废弃，但旧项目残留会导致不可预测的阻塞，建议移除并改用composer/composer原生 asset 处理 - 国内用户务必确认是否用了镜像源（如阿里云、腾讯云），否则
packagist.org直连大概率触发 HTTP 超时而非 process-timeout
真正要调高 process-timeout 的场景其实不多——多数“超时”本质是网络或认证问题。先查 composer diagnose，再看具体卡在哪一步（-v 输出里找最后一行非空日志），别一上来就无脑设成 0。
