Composer超时需分层诊断：DNS问题看Resolving dependencies，HTTP下载卡在Downloading，子进程卡在Executing command，autoload卡住属文件系统或PHP配置；http.timeout控单次HTTP请求（建议300～600秒），process-timeout控总耗时（建议1200秒）；CI中须配国内镜像、--prefer-dist、环境变量COMPOSER_PROCESS_TIMEOUT，并排查硬编码仓库、SSH地址、代理及WSL2元数据配置。
Composer 超时不是单一配置能“一锤定音”的问题，必须区分是 HTTP 下载卡住、子进程执行卡死，还是 DNS/代理层根本连不上——调错参数只会白等。
怎么判断卡在哪一层：看 -vvv 输出的最后一行
运行 composer install -vvv 或 composer update -vvv，重点盯住最后几行输出：
- 停在
Resolving dependencies：大概率是 DNS 解析失败或 Packagist 域名无法访问，跟 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：控制整个composer install命令从开始到结束的总耗时上限，默认 300 秒。它包含解压、运行post-install-cmd、生成 autoloader 等所有步骤。大项目跑脚本时容易超，推荐设为1200（20 分钟） - 注意：
http-basic.timeout是 Composer v1 废弃项，v2 完全不读取，设了也没用
CI/CD 里怎么稳住 composer install
CI 环境更易超时，光拉长 timeout 不够，得组合出手：
- 必须配国内镜像：
composer config -g repos.packagist.org.url https://mirrors.aliyun.com/composer/ - 强制用 dist 包而非源码：
--prefer-dist，避免git clone卡住 - 跳过平台检查要谨慎：
--ignore-platform-reqs只在明确知道缺失扩展不影响构建时才加，否则会掩盖真实兼容性问题 - 环境变量比命令行参数更可靠：
COMPOSER_PROCESS_TIMEOUT=1200比--timeout=1200更能覆盖插件和自定义 installer 启动的子进程 - 别依赖缓存自动恢复——在 GitHub Actions 等场景中，显式加
composer install --no-interaction --prefer-dist --optimize-autoloader
为什么换镜像后还超时？这些点常被忽略
换源只是提速，不是万能解药。以下情况再调 timeout 也白搭：
- 项目
composer.json里硬写了"repositories"，优先级高于全局镜像配置，得手动清理或同步改掉 - 私有包用的是
git@github.com:user/repo.git这类 SSH 地址，镜像不代理 Git 协议；应改用 HTTPS 地址或配好 SSH 密钥 +git config --global url."https://".insteadOf git:// - 公司网络开了代理但没设
https_proxy环境变量，cURL 直接失败；可试curl -v https://mirrors.aliyun.com/composer/packages.json验证 - 本地用了 WSL2 且项目放在
/mnt/c/下，未在/etc/wsl.conf中启用metadata = true，symlink 解析极慢，看起来像卡住
真正难处理的是混合卡点：比如某私有包走 SVN + 自定义 installer，又在 post-update-cmd 里跑前端构建。这种时候必须靠 -vvv 日志逐行定位，而不是盲目把 timeout 设成 0。
