Symfony HttpClient 需用 RetryableHttpClient 并启用 retry_failed 选项才能重试；默认仅对 5xx 和网络错误重试，POST 等非幂等请求需显式配置且依赖服务端支持；常见失效原因为未开启 retry_failed 或遗漏 http_codes。
HttpClient 发送请求时怎么加重试逻辑
Symfony HttpClient 本身不内置重试机制，得自己封装。直接调用 request() 不会自动重试，哪怕网络抖动或 503 响应也会立刻抛异常或返回失败响应。
实操建议：用 RetryableHttpClient 包装原客户端，它属于 symfony/http-client 的可选组件（v5.4+ 内置，无需额外安装）。
- 必须启用
symfony/http-client的retry_failed选项，否则RetryableHttpClient不生效 - 重试策略靠
max_retries和delay_ms控制，不是指数退避，默认线性等待 - 只对特定 HTTP 状态码和网络错误重试（如
5xx、Connection refused），400 类错误默认不重试
$client = new RetryableHttpClient(
new HttpClient(),
[
'max_retries' => 3,
'delay_ms' => 1000,
'http_codes' => [500, 502, 503, 504],
]
);
$response = $client->request('GET', 'https://api.example.com/data');
重试时怎么避免重复提交 POST 请求
POST、PUT、DELETE 默认不重试——因为可能产生副作用。如果你硬要重试，得显式允许，并确保服务端幂等。
实操建议：在 RetryableHttpClient 配置中打开 allow_redirects 和 retry_failed 的同时，用 idempotency_key 类似机制（靠服务端支持），客户端只能配合。
立即学习“PHP免费学习笔记（深入）”；
- 修改默认行为需传
'retry_strategy' => ['methods' => ['GET', 'HEAD', 'POST']]，但 Symfony 不推荐对 POST 开箱即用重试 - 更安全的做法是把业务逻辑包进
try/catch，手动捕获TransportException或检查$response->getStatusCode() - 注意：重试期间
body是重新序列化的，如果用了闭包或资源句柄（如fopen(..., 'r')），第二次会失败
为什么重试后还是没生效？常见配置坑
最常踩的坑是以为配了 max_retries 就万事大吉，其实底层依赖两个开关都打开才行。
-
RetryableHttpClient构造时传的选项只是策略，真正触发重试还要看底层HttpClient是否启用了retry_failed（默认 false） - 别漏掉
'http_codes'—— 如果服务返回 429，但没把它加进数组，就不会重试 - 超时设置（
timeout）太短会导致请求根本没发出去就被 cancel，这种不算“失败”，不会进重试流程 - 使用
Promise异步发送时，重试逻辑只作用于单个 promise，不能跨多个并发请求共享状态
和 Guzzle 的重试比有什么实际差异
不是“谁更好”，而是行为边界不同：Guzzle 的 RetryMiddleware 更灵活（可自定义判定函数），Symfony 的 RetryableHttpClient 更轻、更绑定 HTTP 状态与网络层错误。
- Guzzle 允许你在重试前执行任意 PHP 逻辑（比如刷新 token），Symfony 没这层钩子，得自己 wrap
request() - Symfony 默认重试间隔固定，Guzzle 可配 jitter 或指数退避，但要写回调
- 两者都不处理“请求已发出但响应未收到”的场景（即 timeout + 服务端已处理），这得靠业务层幂等设计兜底
真正在意重试精度和控制力，就别依赖框架封装，老实用 for 循环 + try/catch 手写——尤其是涉及支付、库存扣减这类操作。
