拉取代码中断90%是process-timeout过低所致，需优先调高至600–1200秒，再同步配置GitHub Token、禁用并行下载及调整PHP socket超时。
直接结论：拉取代码中断，90% 是 process-timeout 太低，不是网络问题，也不是 http.timeout 没设对——必须优先调高它，再同步处理 GitHub Token、并行下载和 PHP socket 超时。
卡在 Downloading https:// 或 git clone 时该调哪个 timeout
这是典型的子进程执行超时，错误里带 The process "git clone ..." exceeded the timeout 或反复 retry 后静默失败。此时 process-timeout 是唯一生效的配置项，http.timeout 完全不参与这个阶段。
-
process-timeout控制单个外部命令（如git clone、unzip、tar -xzf）最大允许运行时间，单位秒，默认仅300 - 国内直连 GitHub 时，首字节延迟常达 2–5 秒，并行下载会放大压力，
300秒根本不够用 - 错误日志中若出现
cURL error 28，说明是 HTTP 下载阶段卡住，才轮到http.timeout发挥作用
怎么安全地提高 process-timeout
别一上来就设成 0（禁用超时），容易掩盖挂起或资源耗尽问题。推荐分场景设置：
- 本地开发：运行
composer config -g process-timeout 600（10 分钟），写入全局配置 - CI/CD 环境（如 GitHub Actions）：在步骤中显式加环境变量
COMPOSER_PROCESS_TIMEOUT=900，避免被 runner 默认 PHP 配置覆盖 - 项目级强约束：在
composer.json的config段加"process-timeout": 1200，可提交、可复现 - 临时调试：用
composer install --timeout=1800（注意必须带等号），优先级最高
为什么调高了 process-timeout 还失败
常见原因不是 timeout 没设够，而是其他环节提前掐断了连接：
- PHP CLI 的
default_socket_timeout值太小（常为60），哪怕你设了http.timeout=1200，cURL 底层也会在 60 秒后报cURL error 28；查法：php -i | grep default_socket_timeout，改法：php -d default_socket_timeout=600 composer install - 没配 GitHub Token，API 请求被限流（未认证每小时仅 60 次），几秒就耗尽；配法：
composer config --global github-oauth.github.com <your-token></your-token>，然后chmod 600 ~/.composer/auth.json - 并行下载开启状态下，DNS 解析慢或 socket 资源紧张会加剧超时；禁用法：
COMPOSER_DISABLE_PARALLEL=true
真正卡住时别只盯着 timeout
很多“超时”其实是假象：内存不足时 composer update 在解析锁文件阶段 OOM，表现和超时一模一样；磁盘空间不足会导致 unzip 失败但报错被吞掉；Generating autoload files 阶段卡住，往往是递归扫描 symlink 或嵌套过深的 vendor 包引发 I/O 阻塞。这些情况调 timeout 没用，得看 memory_limit 是否 ≥ 1.5G、df -h 是否充足、是否用了 --no-dev 缩减 autoload 范围。
