Composer镜像连接超时处理_有效提高稳定性-composer-PHP中文网

镜像连接超时主因是dns解析失败、tls握手卡住或镜像源失效，而非composer配置错误；应先验证网络连通性（如curl -v测试），再换有效镜像源（如https://mirrors.aliyun.com/composer/）、清缓存，最后按需调http.timeout（单次http请求）或process-timeout（整条命令）。

composer镜像连接超时处理_有效提高稳定性

镜像连接超时不是 Composer 配置错了，而是 DNS、TLS 或镜像源本身响应慢卡在底层——换源 + 清缓存 + 调 http.timeout 是最短路径，但顺序不能错。

为什么换镜像后还是 `Connection timed out`

常见现象是执行 composer install 卡在 Loading composer repositories，或报 Could not resolve host repo.packagist.org。这不是 Composer 读配置失败，而是系统根本没发出去请求。

DNS 解析失败：运行 ping packagist.org 返回 unknown host，说明 /etc/resolv.conf（Linux/macOS）或网络适配器 DNS（Windows）配置异常，此时改 http.timeout 完全无效
TLS 握手卡住：用 curl -v https://mirrors.aliyun.com/composer/packages.json 看是否停在 * TLS handshake，常见于 WSL2 时间不同步、公司中间件拦截或证书链不全
镜像源已失效：比如仍用已下线的 https://packagist.phpcomposer.com，应换成当前可用地址：https://mirrors.aliyun.com/composer/ 或 https://packagist.proxy.tencent.com/

`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

下载

http.timeout：控制单次 HTTP 请求从 DNS 查询、TCP 连接、TLS 握手到响应头返回的总耗时（单位秒），适用于 Could not fetch https://... 类错误
process-timeout：控制整个 composer install 命令生命周期，包括依赖解析、下载、解压、执行 post-install-cmd 脚本等，超时直接 kill -9
v2 版本已废弃 http-basic.timeout，设了也不生效；http.timeout 必须写在 config.http.timeout 结构里，不能平级放

怎么让配置真正生效且不污染其他项目

全局配置（composer config -g）容易误影响其他项目，CI 环境还可能因容器重启丢失。推荐优先走项目级控制。

在项目 composer.json 的 config 段加：

{
  "config": {
    "http": {
      "timeout": 300
    },
    "process-timeout": 1800,
    "preferred-install": {"*": "dist"}
  }
}

preferred-install 强制走 dist 包，避免触发 git clone（它有自己的超时逻辑，且不响应 process-timeout）
CI 中建议用环境变量固化：COMPOSER_PROCESS_TIMEOUT=1800 和 COMPOSER_HTTP_TIMEOUT=300，优先级高于配置文件
验证是否生效：运行 composer config --list，确认输出里包含对应值

为什么调高 timeout 还是失败，且 `-vvv` 日志没报 timeout 字样

Composer 错误信息常掩盖真实原因。例如反复出现 file_get_contents(): SSL operation failed 或静默重试后退出，大概率是 TLS 握手超时或证书验证失败，而非 HTTP 层超时。

加 -vvv 时只关注前几行：看卡在 * Connected to（DNS/TCP 层）、* TLS handshake（证书或协议问题），还是 之后（才轮到 <code>http.timeout 生效）
若卡在 TLS，临时强制 IPv4：CURL_IPRESOLVE=4 composer install（Linux/macOS）
某些私有 Git 仓库或硬编码的 repositories 会绕过镜像源，导致部分包仍走原始地址，需检查 composer.json 里是否有冗余 repositories 字段

真正麻烦的是混合源场景：公共包走镜像，私有包走 GitHub/GitLab，而 process-timeout 是整条命令共用的。某个私有库卡住，会耗尽全部超时时间——这时得单独优化 VCS 行为，比如配 git.clone-depth=1 或 github-oauth，而不是无差别拉长 timeout。