ThinkPHP 8 的 Http::post()->retry(3) 仅对网络层错误（如502/503/504、超时）生效，需显式设置 timeout；非 Swoole 环境下走 cURL，retry 对业务错误（4xx）无效，且 pool 中各请求重试独立，易引发 QPS 暴增。
ThinkPHP HTTP 请求失败时重试没生效？检查 Http::post() 是否用了底层 cURL 而非 Swoole
ThinkPHP 8 的 think\facade\Http 默认走的是 PHP 原生 cURL，不是 Swoole 协程客户端。如果你在 Swoole 环境（如 Hyperf 或自建协程服务）里混用，retry() 可能被忽略或行为异常。
- 确认当前环境：运行
php -m | grep swoole，若无输出，说明没启用 Swoole，Http::post()就是标准 cURL 行为 - 重试逻辑只对
Http::post()、Http::get()等 facade 方法有效，对直接 newcurl_init()或file_get_contents()无效 - ThinkPHP 6/7 不带内置重试，必须手动封装；TP8 才原生支持
->retry(3)链式调用
TP8 中 Http::post() 的 retry() 怎么设才真正触发？
重试不是“失败就重来三次”，它只对特定网络层错误响应，HTTP 状态码 502/503/504 或连接超时才重试，400/401/404 这类业务错误不会触发。
- 必须显式设置超时：
Http::timeout(3)->retry(2)->post($url, $data)，不设timeout时默认 0（无限等待），根本等不到“失败”就卡住 -
retry(2)表示最多再发 2 次（共 3 次请求），不是“重试 2 秒”或“重试 2 次后放弃”这种模糊理解 - 重试间隔固定为 0 秒（立即重试），无指数退避；如需间隔，得自己封装
for循环 +sleep()
自定义重试逻辑时，try/catch 捕获哪个异常最准？
别 catch Exception，ThinkPHP HTTP 请求抛出的是 think\exception\HttpException 子类，但实际网络失败多由底层 think\exception\Throwable 或 RuntimeException 包裹。
- 推荐捕获
Throwable：它覆盖所有错误类型，包括 DNS 解析失败、连接拒绝、SSL 握手失败 - 如果只关心超时，可判断异常消息是否含
"cURL error 28"或"Operation timed out" - 注意：TP8 在
retry()内部已吞掉部分异常，只有最终失败才会抛出，所以自定义重试要绕开retry()直接用Http::create()实例
并发请求下重试导致 QPS 翻倍？小心 retry() 和 pool() 的组合陷阱
用 Http::pool() 发起多个请求时，每个子请求的 retry(2) 是独立执行的。10 个请求 × 最多重试 2 次 = 最坏情况发出 30 次 HTTP 调用，下游服务可能直接被打挂。
立即学习“PHP免费学习笔记（深入）”；
- 避免在
pool()里对每个请求都开retry()，应统一做熔断或降级，比如先用cache()->get()查缓存，命中则跳过请求 - 重试 + 并发场景下，建议加简单去重：用
md5($url . json_encode($data))作 key，失败后写入 Redis 5 秒锁，防止同一失败请求被多个进程重复重试 - TP 自带的
retry()不支持熔断器（如 Circuit Breaker），复杂容错必须引入thans/think-circuit-breaker这类扩展
重试本身很简单，难的是判断“该不该重试”——接口幂等性、下游是否真抖动、重试是否让问题更糟，这些没法靠加个 retry(3) 解决。
