必须同时调高 http.timeout 和 process-timeout，否则 CI 流程大概率在下载或解压阶段中断；http.timeout 控制 HTTP 请求总时间，process-timeout 控制 unzip 等子进程执行时间，PHP 的 default_socket_timeout 和 max_execution_time 也需同步调整以避免三层超时错位。
必须同时调高 http.timeout 和 process-timeout，否则 CI 流程大概率在下载或解压阶段中断——这不是“慢”，是被硬性掐断。
卡在 Downloading https:// 时该调哪个参数
这是 HTTP 请求生命周期超时，错误里常带 cURL error 28 或反复 retry。它只响应 http.timeout，和 process-timeout 无关。
-
http.timeout控制 DNS + TLS 握手 + 首字节等待 + 整个 ZIP 包 body 传输的总时间，默认仅 300 秒，弱网下拉一个 200MB 的 dist 包必然失败 - 项目级生效：运行
composer config http.timeout 1200，写入当前composer.json的config段，可提交、可复现 - 全局生效（推荐 CI 共享配置）：运行
composer config -g http.timeout 1200，写入~/.composer/config.json - ⚠️ 关键但常被忽略：PHP CLI 的
default_socket_timeout必须 ≥http.timeout，否则 cURL 在底层直接报错——用php -i | grep default_socket_timeout查，若为 60，需同步改php.ini或用php -d default_socket_timeout=1200启动
The process timed out 错误该调哪一项
错误信息里一定含 [RuntimeException] The process "" exceeded the timeout，加 -vvv 能看到最后执行的命令，比如 unzip -qq 或 git clone —— 这是子进程超时，和网络下载无关。
-
process-timeout控制单个外部命令（如unzip、git clone、tar -xzf）最大执行时间，默认 300 秒，解压大 dist 包或私有仓库 clone 很容易触发 - CI 环境最稳做法：用环境变量兜底，
COMPOSER_PROCESS_TIMEOUT=1800，优先级高于配置文件，且不依赖本地composer.json - 临时调试可用
--timeout=1800，注意必须带等号：composer install --timeout=1800；写成--timeout 1800会被静默忽略 -
config.timeout是无效字段，Composer 根本不识别，别往composer.json里写这个
脚本执行超时（如 post-install-cmd）不是 Composer 控的
Composer 自己不管理脚本执行时间，它只是调用 PHP 进程跑你的代码。超时由 PHP 自身机制决定，常见报错是 Maximum execution time of XXX seconds exceeded。
- 最可靠方式：启动时用
php -d max_execution_time=0，例如php -d max_execution_time=0 composer install - 若用 GitHub Actions，显式写
php -d max_execution_time=900 composer install --no-interaction，避免 runner 默认值（常为 30 或 60）提前 kill - 脚本内部调
set_time_limit()也有效，但必须在早期执行，且不能在disable_functions禁用该函数的环境中使用 - 注意：PHP 的
max_execution_time和 Composer 的process-timeout是两套独立机制，别混淆
真正卡住持续交付的，往往不是某一个 timeout 参数没调对，而是 HTTP 层、子进程层、PHP 脚本层三者超时阈值错位——比如 http.timeout 设了 1200，但 default_socket_timeout 还是 60，结果连握手都过不去。每次调参前，先确认这三层是否对齐。
