如何利用Composer集成 Guzzle-Retry-Middleware 库实现接口调用的自动重试

直接安装 caseyamcl/guzzle_retry_middleware 后需配置 HandlerStack、设置 http_errors => false 并指定 timeout，否则重试不生效；Guzzle 7+ 要求 PHP >= 7.2，低版本需降级至 ^0.1；国内需切阿里云镜像源并清缓存；decider 须同时处理 $response 和 $exception；retry_delay 单位为毫秒，指数退避需设最大等待上限。

直接装 caseyamcl/guzzle_retry_middleware 就能用，但不配 handler 堆栈、不关 http_errors、不设 timeout，重试根本不会触发——多数人卡在这三步。

composer require 之后必须检查 PHP 版本和镜像源

装不上大概率不是库的问题，而是环境没对齐：

• caseyamcl/guzzle_retry_middleware:^0.2 要求 Guzzle 7+，而 Guzzle 7 需 PHP >= 7.2；若你用的是 PHP 7.0 或 7.1，得降级：运行 composer require caseyamcl/guzzle_retry_middleware:^0.1
• 国内默认源经常超时，别只靠 -vvv 看卡在哪，先切阿里云镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 如果提示 Could not delete vendor/...，说明缓存残留，先执行 composer clear-cache 再重试

重试中间件必须挂到 HandlerStack，不能只传配置数组

很多人以为给 new Client(['retry' => 3]) 就能重试，其实 Guzzle 官方 retry 配置项只在 HandlerStack 场景下生效。不走堆栈，retry 参数会被忽略。

• 正确写法是：用 GuzzleHttpHandlerStack::create() 创建 handler，再 push() 中间件
• 别漏掉 http_errors => false —— 否则遇到 502/503 直接抛 ServerException，decider 根本收不到 $response，重试逻辑就断了
• 示例关键片段：

  $stack = HandlerStack::create();$stack->push(RetryMiddleware::factory($options));$client = new Client(['handler' => $stack, 'http_errors' => false]);

decider 函数决定“重不重试”，status code 和 exception 必须分开判

常见错误是只判断 $response，结果超时（$exception 不为空）时完全跳过重试。

• 必须同时处理两个分支：$response 存在时看状态码（如 5xx、408）；$exception 存在时判断类型（如 ConnectException、TimeoutException）
• 别写 if ($response && $response->getStatusCode() >= 500) 就完事，漏掉 $exception instanceof GuzzleHttpExceptionConnectException 会导致连接失败不重试
• 注意：Guzzle 7 默认把 4xx 当异常抛，所以如果你开了 http_errors => true，decider 里 $response 永远为 null，只能靠 $exception 判断

retry_delay 和 intervalFunction 的单位容易搞反

文档里写的 “毫秒”，但实际传整数会被当成毫秒，传闭包返回值也必须是毫秒——可一旦误当秒用，重试间隔会变成 1000 秒起步。

• 'retry_delay' => 1000 = 等 1 秒后重试
• 用闭包自定义时，返回值单位仍是毫秒：function ($n) { return $n * 500; } 表示第 1 次等 500ms，第 2 次等 1000ms
• 如果想实现指数退避，别手写 pow(2, $n) * 100，要加 min(..., 30000) 限制最大等待，否则第 6 次重试就要等 3.2 秒，可能超出整体 timeout

真正难的不是写 decider 或调 interval，而是搞清哪类错误该重试、哪类该立刻失败——比如 401/403 通常不该重试（认证失效），而 429 可能需要配合 Retry-After 头做动态等待，这些逻辑没法靠中间件自动推导，得你自己在 decider 里解析响应头。