90%是process-timeout太小所致，它专管git clone、unzip等子进程，默认300秒，可项目级设为1200、全局设为-g或临时用--process-timeout=1200覆盖。
Composer 执行卡住或报 The process "git clone ..." 错误，90% 是 process-timeout 太小，不是网络问题，也不是镜像源没换对——直接调这个值最有效。
为什么 process-timeout 一设就灵
它专管 Composer 自己启动的外部命令：比如 git clone、unzip、php ./vendor/bin/xxx 这类操作。默认 300 秒（5 分钟），但克隆一个含大二进制文件的私有仓库、解压 Laravel 全量包、跑一次全量测试脚本，很容易超时。
- 错误典型表现：
[RuntimeException] The process "git clone ..." exceeded the timeout of 300 seconds. - 和网络无关：哪怕所有包都已缓存，
post-install-cmd脚本跑太久也会被杀 - 不解决
cURL error 28：那是 HTTP 层超时，得调http-timeout或换镜像
怎么设才真正生效
优先级是：命令行参数 > 项目 composer.json > 全局配置。别只改全局却在项目里覆盖了，也别只改项目却忘了 CI 环境没同步。
- 临时救急（单次命令）：
composer install --process-timeout=1200（单位秒，支持小数） - 项目级（推荐）：编辑
composer.json，在顶层加"config": { "process-timeout": 1200 }，然后运行composer install即可读取 - 全局设置（开发机常用）：
composer config -g process-timeout 1200，写入~/.composer/config.json，注意必须带-g，漏掉就变成改当前项目了 - 设为
0表示禁用检查——不推荐。远程 Git 仓库彻底不可达时会无限卡住，掩盖真实问题（比如死循环脚本）
设多少才算合理
600～1800（10～30 分钟）是安全区间。再大反而难定位问题：你分不清是真慢，还是进程已假死。
- CI 构建首次拉依赖？设
1200足够 - 本地调试含大量 post-install 脚本的旧项目？
1800更稳妥 - PHP
max_execution_time可能比process-timeout更早中断，尤其在共享主机或 Docker 容器里，记得检查php.ini - Windows 用户若用 Scoop 安装 Composer，
config -g可能因权限失败，可改用项目级配置或手动编辑%USERPROFILE%\AppData\Roaming\Composer\config.json
容易被忽略的关键点
很多人调了 process-timeout 还失败，是因为没意识到：它只管「子进程」，不管「HTTP 连接」；也不管「GitHub 限流」；更不管「DNS 解析慢」或「系统时间不同步导致 TLS 握手失败」。
- 看到
cURL error 28或Could not fetch https://...循环重试？那是http-timeout或网络层问题，该换镜像或查curl -v输出 - 用私有 GitLab/Bitbucket？SSH key 权限、
git.clone-depth、代理配置可能比 timeout 更关键 - 改完配置后，务必运行
composer config -g --list | grep timeout确认是否写入成功——手动编辑 JSON 容易格式出错
