答案：需根据-vvv输出最后一行精准定位卡点——停在Resolving dependencies是DNS或域名访问问题；停在Downloading是HTTP超时，调http.timeout；停在Executing command是子进程卡死，调process-timeout或COMPOSER_PROCESS_TIMEOUT；停在Generating autoload files是文件系统或PHP配置问题。
看 -vvv 输出最后一行，直接定位卡点类型
Composer 超时不是“慢”，而是卡在某个明确环节。运行 composer install -vvv 或 composer update -vvv，别扫全屏日志，只盯住最后几行输出：
- 停在
Resolving dependencies：DNS 解析失败或 packagist.org 域名不可达，跟 timeout 参数无关；可试dig packagist.org或换 DNS（如114.114.114.114） - 停在
Downloading https://...：HTTP 层超时，http.timeout才管用 - 停在
Executing command (CWD: ...)：子进程（如git clone、unzip）卡死，该调process-timeout或环境变量COMPOSER_PROCESS_TIMEOUT - 停在
Generating autoload files后无响应：不是网络问题，是文件系统或 PHP 配置问题（如 WSL2 symlink 解析慢、APCu 未启用 CLI 模式）
http.timeout 和 process-timeout 到底该调哪个
这两个参数作用完全不同，混着调等于蒙眼改配置：
-
http.timeout：控制单次 HTTP 请求（含 DNS 查询、TLS 握手、首字节等待、body 传输）最大秒数，默认仅 60 秒；下载大包（如laravel/framework）或镜像首字节延迟高时最先触发失败；建议设为300～600 -
process-timeout：控制整个命令从开始到结束的总耗时上限，默认 300 秒；它包含解压、运行post-install-cmd、生成 autoloader 等所有步骤；CI 中必须显式设为1200或更高 - 注意：
COMPOSER_PROCESS_TIMEOUT环境变量优先级高于process-timeout配置项，部分 Composer 版本只认前者
国内用户绕过超时，不能只换镜像源
阿里云、腾讯云等镜像只加速公共包下载，对硬编码的私有仓库、SSH 地址、GitHub/GitLab 的 git@ 或 https://github.com/xxx 源完全无效：
- 全局换源命令是
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 但
composer.json里的repositories字段优先级更高，得手动检查并清理冗余项 - 私有 GitLab/GitHub 包别加进镜像配置——镜像不代理 VCS，反而会报
Failed to clone https://xxx: could not connect to server - CI/CD 中务必同时设置
COMPOSER_PROCESS_TIMEOUT=1200和COMPOSER_HOME，否则容器重启后配置丢失
卡在 Generating autoload files 的真实原因
这不是超时，是 PHP 进程在递归扫描大量文件时被阻塞，常见于以下场景：
- WSL2 下
vendor/中存在大量 symlink，PHP 解析极慢 - Docker for Mac 挂载 NTFS 卷，I/O 延迟高
- PHP CLI 模式未启用 APCu，autoload 生成阶段反复读取文件
- 项目中存在深度嵌套的包（如某些旧版 Symfony bundle），触发 PHP 默认的
max_execution_time限制 - 临时验证方法：运行
php -d max_execution_time=0 -d memory_limit=-1 vendor/autoload.php看是否能加载成功
真正难处理的不是 timeout 数值本身，而是把“卡在 downloading”当成网络问题去调 process-timeout，或者把“卡在 Generating autoload files”当成超时去加镜像——错位诊断，只会浪费时间。
