http.timeout控制HTTP层总耗时（DNS、TLS、首字节、body传输），卡在Downloading https://时应调此参数；process-timeout控制git clone等子进程执行时间，两者缺一不可。
直接改 http.timeout 和 process-timeout，缺一不可——前者管下载 ZIP、拉 packages.json，后者管 git clone、解压、执行脚本。只调一个，大概率还是卡。
卡在 Downloading https:// 时该调哪个参数
这是 HTTP 层卡住，比如拉元数据或下载压缩包，错误里常带 cURL error 28 或反复 retry 后失败。它完全不看 process-timeout，只认 http.timeout（Composer 2.x）。
-
http.timeout控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输的总时间，默认仅 300 秒，弱网下极易触发 - 项目级最稳：运行
composer config http.timeout 600，写入当前composer.json的config段，可提交、可复现 - 全局生效：用
composer config -g http.timeout 600，写入~/.composer/config.json - 临时覆盖优先级最高：设环境变量
COMPOSER_HTTP_TIMEOUT=1200 composer install，适合 CI 调试 -
⚠️ 关键同步项：运行
php -i | grep default_socket_timeout查出的 PHP CLIdefault_socket_timeout若低于你设的http.timeout（常见值是 60），连接会被 PHP 提前掐断，务必同步调高
The process timed out 错误该调哪一项
这是子进程执行太久被杀，比如 git clone、unzip、跑 post-install-cmd 脚本。错误里一定含 [RuntimeException] The process "" exceeded the timeout，加 -vvv 可看到最后那条命令。
-
process-timeout控制单个外部命令最大执行时间，默认 300 秒，和 HTTP 完全无关 - 全局改：运行
composer config -g process-timeout 1800（30 分钟），写入~/.composer/config.json - 项目级改：直接在
composer.json顶层加"config": {"process-timeout": 1200} - 临时覆盖：用
COMPOSER_PROCESS_TIMEOUT=1800 composer install或命令行参数--process-timeout=1800 - 设为 0 表示禁用超时，但可能卡死无响应；调试建议先设 600，确认能走通再调高
为什么换源比调 timeout 更有效
单纯延长超时只是“等得更久”，不能解决网络不稳定、DNS 慢、镜像回退拖慢等根本问题。国内用户不切镜像，--timeout=3600 也救不了连不上 packagist.org 的情况。
- 阿里云镜像是目前最稳定可用的国内源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 必须禁用 fallback：
composer config -g repo.packagist false，防止 Composer 自动回退到官方源 - 验证是否生效：
composer config -g repo.packagist应输出对应 URL - 注意：某些项目硬编码了
repositories字段，会覆盖全局配置，得手动清理冗余项
真正卡住时，别只盯着 timeout —— 内存不足（memory_limit 建议 ≥ 1.5G）、用了 "type": "vcs" 导致每次 git clone 都计入总超时、或 Generating autoload files 阶段 I/O 阻塞，都可能伪装成超时。调参前先 composer config -l 看清当前生效值，再结合 -vvv 日志定位真实卡点。
