并发请求仅将等待时间并行化，不解决API调用慢的本质问题；需关注超时、重试、错误处理及响应解析效率，合理使用Http::pool()并逐个验证响应状态。
并发请求
本身不解决第三方 API 调用慢的问题，它只把“等的时间”从串行变并行。真正卡住的，往往是单个请求的超时、重试逻辑缺失、错误未显式处理，或响应体解析方式低效。
Http::pool() 是并发首选，但必须显式检查每个响应状态
很多人以为
返回数组就万事大吉，其实每个响应对象都需单独验证。不调用
或
，就可能把 401/502 当作正常数据往下传。
正确做法：对每个响应调用
（抛异常）或
+
组合
常见错误：直接
，遇到空响应或非 JSON 会返回
，后续数组操作报
推荐写法：
，失败时自动抛
，可集中 try/catch
并发不是万能的，别在循环里滥用 Http::pool()
比如要查 100 个用户的状态，写成 100 次
调用，反而比串行更慢——连接复用失效、DNS 查询重复、HTTP/2 流控被挤爆。
真正适合并发的场景：固定数量、已知 URL 的几个接口（如用户基础信息 + 订单统计 + 通知设置）
大量 ID 批量查询，应优先走第三方 API 是否支持批量 endpoint（如
），而不是硬拆并发
若必须分批，并发组数建议 ≤ 5，每组内请求数 ≤ 3，避免压垮对方服务或触发限流
超时和重试必须按接口粒度配置，不能全局统一
查天气 API 可能 2s 就返回，而支付回调确认可能要等 15s；一个
套所有接口，要么超时太短频繁失败，要么太长拖垮整体响应。
为不同业务场景建命名 client：
设 timeout=3，
设 timeout=12
重试只应对网络抖动类错误（
、
），不应对 400/404 这类业务错误重试
使用
精确控制重试范围
并发响应体解析要避免重复 json_decode
返回的是多个
实例，每个调用
都会重新解析一次 JSON 字符串——如果响应体大、字段多，这部分 CPU 开销不可忽略。
只需一次解析：先
，再从
中取值，不要反复调
若需结构化数据，建议封装成 DTO 类，构造时传入
结果，避免后续多次访问属性时隐式解析
注意：不要在 Blade 模板里直接写
，这会在每次渲染时重复解析
最常被忽略的一点：并发请求的错误日志必须带上下文标签。比如 pool 中某个请求失败，光记
毫无意义，得记录是哪个 key（
还是
）、URL、请求耗时、原始响应头。否则线上出问题，你得靠猜。
Http::pool()->successful()->failed()->throw()->ok()->json()json_decode($response->body(), true)nullTrying to access array offset on value of type null$responses['user']->throw()->json()Illuminate\Http\Client\RequestExceptionHttp::pool()/users?ids=1,2,3Http::timeout(5)->retry(2)Http::client('weather')Http::client('payment')ConnectExceptionRequestException->retry(3, 100, \GuzzleHttp\Exception\ConnectException::class)Http::pool()Illuminate\Http\Client\Response->json()$data = $response->json()$data$response->json()['user']['name']$response->json(){{ $response->json()['status'] }}"HTTP request failed"'inventory''price'