Composer如何配置HTTP超时时间？（网络稳定性优化）

composer的http超时由http-timeout配置项控制，单位秒，默认300；需用composer config [–global] http-timeout n设置，而非http-basic；镜像源切换比单纯调高超时更有效。

composer config http-basic 超时无效？别配错位置

Composer 的 HTTP 超时不是通过 http-basic 配置项控制的——这个配置只管认证凭据，跟超时完全无关。真正起作用的是全局或项目级的 http-timeout 配置项，单位是秒，默认值是 300（5 分钟），但弱网下往往不够用。

常见错误现象：composer install 卡在 “Downloading https://packagist.org/packages.json” 几分钟后报 curl Error 28: Operation timed out after 300000 milliseconds，说明默认 300 秒已触发，但你改了 http-basic 完全没效果。

• 必须用 composer config --global http-timeout 600（全局）或 composer config http-timeout 600（当前项目）设置
• 该值仅影响 Composer 自身的 HTTP 请求（如元数据拉取、zip 下载），不影响 vendor 内代码运行时的网络调用
• 若同时用了私有仓库，需确认其响应头未强制限制 client-side timeout（比如 nginx 的 proxy_read_timeout）

为什么 set_time_limit(0) 对 composer install 无效

PHP 脚本超时（max_execution_time）和 Composer 的 cURL 层超时是两层独立机制。即使你在 composer.phar 所在环境里执行了 set_time_limit(0)，也完全不影响底层 cURL 的 CURLOPT_TIMEOUT 行为。

真实使用场景：CI 环境中因 DNS 解析慢或中间代理抖动，导致单次请求耗时波动大；这时只调高 PHP 执行时间毫无意义，必须让 cURL 层允许更长等待。

• http-timeout 最终会映射为 cURL 的 CURLOPT_TIMEOUT，而非 CURLOPT_CONNECTTIMEOUT
• 如需单独控制连接建立阶段（比如代理握手慢），得用 composer config --global github-protocols https + 提前配置系统级 cURL 配置（如 ~/.curlrc 中设 connect-timeout = 30）
• 注意：某些共享主机禁用 http-timeout 修改，会静默忽略配置，此时只能换本地执行或改用 COMPOSER_HTTP_TIMEOUT=600 composer install 环境变量方式

HTTP 超时和 mirror 加速的关系

调高 http-timeout 不等于解决慢，只是避免误判失败。国内用户更应优先切换镜像源，否则再高的超时也只是“耐心等失败”。Packagist 官方不提供中国节点，但阿里、腾讯、华为云都有稳定镜像。

容易踩的坑：部分镜像文档写的是 https://mirrors.aliyun.com/composer/，但实际要配成 https://mirrors.aliyun.com/composer（末尾不能带斜杠），否则 Composer 会拼出双斜杠导致 404。

• 推荐命令：composer config --global repos.packagist composer https://mirrors.aliyun.com/composer
• 镜像源生效后，http-timeout 可适当回调到 180～240，既防卡死又避免无谓等待
• 如果用了自建 Satis 或 private Packagist，务必检查其 allow_url_fopen 和 TLS 版本支持（Composer 2.2+ 强制要求 TLS 1.2+）

CI 环境中超时配置容易被覆盖

GitHub Actions、gitlab CI 等平台常预装 Composer，且可能自带缓存策略或 wrapper 脚本。直接跑 composer config --global 可能被后续步骤重置，或因非交互式 shell 导致配置未持久化。

典型表现：本地 composer config --global http-timeout 生效，但 CI 日志里依然看到 “Operation timed out after 300000 milliseconds”。

• CI 中优先用环境变量：COMPOSER_HTTP_TIMEOUT=600 composer install
• 若用 GitHub Actions，确保在 composer install 步骤前加 run: composer config --global http-timeout 600，且该步骤与 install 在同一 job、同一 container
• 某些 CI 镜像把 Composer 缓存挂载到 tmpfs，重启即丢配置——此时必须每次执行前显式设置

网络不稳定时，超时值不是越大越好；关键在分层处理：DNS 和连接阶段用系统级 cURL 控制，传输阶段靠 http-timeout，而根本解法永远是减少对远端的依赖——镜像、缓存、离线 fallback 这些才真正压低失败率。