提升构建成功率：利用Composer重试机制应对网络抖动异常-composer-PHP中文网

composer无--retry开关，需通过composer_process_timeout、process-timeout、http-timeout调优，配合国内镜像、清缓存、dns优化及shell封装重试逻辑来提升弱网稳定性。

提升构建成功率：利用composer重试机制应对网络抖动异常

Composer 本身没有 --retry 这样的开关，但网络抖动导致的下载失败（比如 cURL error 28、Connection refused、Operation timed out）完全可以通过组合配置和环境变量来稳定应对——关键不是“重试多少次”，而是让每次请求更耐扛、失败后有 fallback、整体命令不被轻易中断。

为什么直接加 --retry 不行？Composer 没这个参数

很多人搜 composer retry 会误以为存在类似 npm install --retry=3 的选项，实际没有。Composer 的重试行为是隐式的、有限的（默认仅 2 次），且只作用于单个 HTTP 请求层面，无法覆盖 DNS 解析失败、TLS 握手卡住、或整个命令执行超时等场景。

真正起效的是三层控制：

COMPOSER_PROCESS_TIMEOUT：控制整个 composer install 命令最多跑多久（单位秒），避免被 CI 超时 kill
process-timeout 配置项：Composer 内部用它判断「某个操作是否该放弃」，比如解压 zip、运行脚本，它不控制 HTTP 下载，但影响整体流程韧性
HTTP 层重试依赖 cURL 行为，Composer 不干预；必须靠镜像稳定性 + 网络层兜底（如 CURL_IPRESOLVE=4）来减少失败概率

怎么让 composer install 在弱网下自动多试几次？

没有“自动重试 N 次”的魔法开关，但可以用 shell 封装一层简单而可靠的重试逻辑，尤其适合 CI 脚本：

例如在 GitHub Actions 或 GitLab CI 中写：

Discussion Composer

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

下载

for i in {1..3}; do
  composer install --no-interaction --prefer-dist && break
  sleep $((i * 5))
done

这比依赖 Composer 自身重试更可控，原因如下：

每次失败后清空部分状态（比如临时解压目录），避免残留损坏文件干扰下一次
指数退避（sleep $((i * 5))）给网络恢复留出时间，不是盲目连戳
配合 --prefer-dist 强制走 zip 包，跳过 git clone 这类更易被拦截的操作
不加 --no-scripts 时，某些 post-install-cmd 可能卡住，重试整条命令比单独重试某一步更稳妥

哪些配置项真正影响“重试成功率”？

以下配置不是锦上添花，而是直接影响弱网下能否撑到下载完成：

composer config -g process-timeout 1800：把默认 300 秒拉到 30 分钟，防止大项目中途被 abort
composer config -g http-timeout 600：调高单次 HTTP 请求上限（注意：这不是重试次数，是每趟连接最多等多久）
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/：镜像源不稳定，重试十次也白搭；阿里云镜像 CDN 覆盖广、同步快，是性价比最高的前置优化
composer clear-cache：缓存损坏（如部分 zip 下了一半）会导致后续所有重试都校验失败，报 file could not be downloaded，必须先清
COMPOSER_AUTH={"github-oauth": {"github.com": "xxx"}}：避免因 GitHub API 限流（未登录/令牌失效）触发看似网络问题的 401 错误

CI 中最容易忽略的两个“假性超时”点

很多 CI 报 “timeout” 其实根本不是网络慢，而是卡在非下载环节：

DNS 解析阻塞：容器内用的 114.114.114.114 在某些地区返回错误 IP，换成 223.5.5.5（阿里 DNS）或 8.8.8.8 后立刻变快
PHP OpenSSL 不支持 TLS 1.2：低版本 PHP 编译时没启用 modern TLS，连接新镜像站会静默失败；运行 php -r "print_r(stream_get_transports());" 确认输出含 ssl 和 tls

这些点不排查，光调重试参数只是在给错误路径加马力。