如何解决Composer在低速网络环境下的超时-composer-PHP中文网

卡在downloading https://时应调http.timeout参数，它控制dns解析、tls握手、首字节等待及整个body传输总时间，默认300秒，弱网下易超时，需同步调高php的default_socket_timeout。

如何解决composer在低速网络环境下的超时

composer 在低速网络下超时，根本不是“连不上”，而是默认阈值太保守——弱网下 DNS 解析慢、TLS 握手卡顿、首字节等待久、大包传输慢，全被 http.timeout 和 process-timeout 一并掐断。单纯加参数只是硬等，必须组合调参 + 换源 + 底层加固。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

卡在 Downloading https:// 时该调哪个参数

这是 HTTP 请求阶段卡住，比如拉 packages.json、下载 ZIP 包，错误里常带 cURL error 28 或反复 retry 后失败。它不看 process-timeout，只认 http.timeout（Composer 2.x）。

http.timeout 控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输的总时间，单位秒，默认仅 300（5 分钟），弱网下极易触发
项目级最稳：运行 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 CLI default_socket_timeout 若低于你设的 http.timeout，会提前掐断连接——常见值是 60，务必同步调高

报 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.json 顶层加 "config": {"process-timeout": 1200}
CI 环境建议用环境变量兜底：COMPOSER_PROCESS_TIMEOUT=2000，某些 Composer 版本对它更敏感
设为 0 表示不限时，但不推荐——万一远程 Git 仓库彻底不可达，会无限挂起

为什么换镜像比配代理更可靠

Composer 默认走 HTTPS，多数本地或公司 HTTP 代理不支持 CONNECT 隧道，导致卡在 Downloading https://。镜像源是完整缓存+反向代理，无协议兼容问题，且响应稳定。

推荐阿里云镜像：composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@0
中科大镜像同样稳定：composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@1
切换后务必禁用 packagist.org 回源：检查 composer.json 里是否硬编码了 repositories，否则仍可能 fallback 到官方源
私有 Git 包（如 git@github.com:user/repo.git）不受镜像影响，需单独处理：改用 HTTPS 克隆，或配置 GIT_SSH_COMMAND

容易被忽略的底层限制点

很多用户调高了所有 Composer 参数仍失败，是因为没触达真正瓶颈。

PHP 的 default_socket_timeout 必须 ≥ http.timeout，否则 cURL 还没发完请求就被 PHP 层截断
curl.cainfo 路径若错误，TLS 握手会卡在证书验证环节，表现为长时间无响应而非明确报错
Docker 或 WSL2 环境下，vendor/ 目录若挂载在 NTFS 卷上，Generating autoload files 阶段可能因 I/O 阻塞超时，和网络无关
--prefer-dist 比 --prefer-source 更抗弱网，后者强制走 git clone，对 SSH/Git 连接稳定性要求更高

调参不是终点，低速网络下真正关键的是把「不确定等待」变成「确定性行为」：换镜像消除网络抖动，调底层 timeout 防止过早中断，再辅以 --no-scripts --no-plugins 缩短非必要耗时——这些组合动作做完，才能让 composer install 在 2G 网络或跨国专线抖动时依然跑通。