卡在Downloading时应调http.timeout，它控制DNS解析、TLS握手、首字节等待及整个body传输，默认300秒，弱网下易超时，需同步确保PHP的default_socket_timeout不小于该值。
不能“解除”超时，只能设为 0 禁用——但禁用后一旦卡死，命令会无限挂起，没有自动中断机制。
composer install/update 卡在 downloading 时该调哪个 timeout
这是 HTTP 下载阶段（拉 packages.json、下载 ZIP 包）卡住，错误里常含 cURL error 28 或反复 retry。它只响应 http.timeout，和 process-timeout 无关。
-
http.timeout控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输的总时间，默认仅 300 秒 - 项目级写入：
composer config http.timeout 600（推荐，可提交到版本库） - 全局生效：
composer config -g http.timeout 1200 - 临时覆盖（CI 最常用）：
COMPOSER_HTTP_TIMEOUT=1800 composer install - ⚠️ 必须同步检查 PHP 的
default_socket_timeout：运行php -i | grep default_socket_timeout，若值低于你设的http.timeout（比如默认 60），连接会在 PHP 层被提前掐断
The process timed out 错误该改 process-timeout 还是 http-basic-timeout
错误信息里明确含 [RuntimeException] The process "" exceeded the timeout，说明是某个子进程（如 git clone、unzip、post-install-cmd 脚本）执行太久被杀。这时要调的是 process-timeout，不是 http-basic-timeout（后者只控制单次 HTTP 请求的连接/读取时限，Composer 2.2+ 才支持）。
-
process-timeout默认 300 秒，每次git clone、unzip都单独计时 - 临时改：用
--process-timeout=1200或环境变量COMPOSER_PROCESS_TIMEOUT=1200 - 永久改：运行
composer config -g process-timeout 1800 - 设为 0 表示禁用，但不建议——一旦某次
git clone因 SSH 配置错误卡住，命令就再也退不出来
为什么 set_time_limit(0) 对 composer install 无效
因为 composer install 是主 PHP 进程，它通过 proc_open() 启动一堆子进程干下载、解压、跑脚本的事。set_time_limit() 只作用于当前 PHP 进程，管不了子进程。
- 你在
post-install-cmd脚本里调set_time_limit(0)是有效的，但只保这个脚本自身 - 你在自定义类中调，必须确保它在脚本入口第一行就执行，否则可能被后续逻辑覆盖
- PHP CLI 模式下若
max_execution_time被disable_functions禁用，则直接报错，不是静默失效
真正卡住时，别只盯着 timeout 参数——内存不足（memory_limit ＜ 1.5G）、没切国内镜像、repositories 里硬编码了不可达的私有源，都会表现为“超时”，但本质是阻塞或失败，不是慢。
