Composer 默认 process-timeout 为300秒，超时后强制终止 git clone 等子进程；可全局设为 composer config -g process-timeout 1800，或项目级在 composer.json 中配置 "config": {"process-timeout": 1200}。
composer install 或 update 卡住后自动中断？看 process-timeout
默认情况下，Composer 在执行耗时命令（比如 git clone、unzip、脚本钩子）时，会等待 300 秒（5 分钟）后强制终止。这不是网络超时，而是「单个外部进程运行时间」上限——哪怕 git 正在慢速拉取大仓库，也会被砍掉。
常见错误现象：[RuntimeException] The process "git clone ..." exceeded the timeout of 300 seconds. 或卡在 Installing dependencies 阶段不动，几秒后直接报错。
- 修改方式是设置
process-timeout配置项，单位为秒，支持全局或项目级 - 它只影响 Composer 自己调用的子进程（如
git、unzip、php脚本），不影响 HTTP 请求（那是http.timeout管的） - 设为
0表示禁用超时，但不推荐——万一远程仓库彻底挂了，会无限卡住
全局修改：所有项目都生效
适合开发机上长期面对私有 Git 仓库、内网镜像或慢速网络的场景。命令行执行即可：
composer config -g process-timeout 1800
这会写入 ~/.composer/config.json。注意：-g 参数必须显式带上，漏掉就变成改当前项目配置了。
- 值建议控制在
600～3600之间，10～60 分钟足够应对绝大多数慢操作 - Windows 用户要注意路径权限：如果 Composer 是通过 scoop/chocolatey 安装的，可能需要管理员权限才能写入全局配置
- 改完后无需重启终端，下次
composer install就生效
项目级修改：只影响当前 composer.json 所在目录
更适合 CI/CD 流水线或临时调试，避免污染全局环境。直接编辑项目根目录下的 composer.json，在顶层加字段：
{
"config": {
"process-timeout": 1200
}
}
然后运行 composer install 或 composer update —— Composer 会自动读取并应用该配置。
- 这个值优先级高于全局配置，项目里设了就以项目为准
- 不要把它写进
require或scripts里，config必须是顶层键 - CI 环境中若用
--no-interaction，也要确保config已存在，否则不会提示你补填
为什么改了还是超时？检查这几个地方
process-timeout 不起作用，大概率是混淆了其他超时机制：
- HTTP 层超时：如果卡在
Downloading https://...，那是http.timeout在起作用，不是process-timeout - Git 本身超时：某些企业 Git 服务（如 Gitee 私有版）可能自带连接限制，Composer 改了没用，得调 Git 的
core.sshCommand或http.postBuffer - Docker 或容器限制：在 CI 容器里运行时，可能被
timeout命令或 KubernetesactiveDeadlineSeconds截断，和 Composer 无关 - PHP
max_execution_time：CLI 模式下默认是 0，但有些定制 PHP 环境会设成 30 秒，导致整个composer进程被 PHP 中止
真正容易被忽略的是：Composer 的 process-timeout 只计子进程真实运行时间，不包括等待调度、I/O 阻塞这些——所以磁盘满、内存不足、DNS 解析失败时，它也救不了你。
