直接调用request()不自动抛异常或校验状态码，需显式检查getStatusCode()；异步请求须用requestAsync()+Promise等待；重试需RetryableHttpClient并启用retry_failed及http_codes配置。
直接调用 request() 是最常用、也最容易出错的起点
几乎所有 Symfony HttpClient 的使用都从 request() 开始，但它不自动抛异常，也不校验状态码——这和 Guzzle 的默认行为截然不同。你拿到的 $response 对象永远存在，哪怕服务返回 503 或根本连不上。
常见错误现象：Class "Symfony\Component\HttpClient\HttpClient" not found，多半是没运行 composer dump-autoload，或项目用了 Symfony 全栈但误删了 autoload 配置。
- 必须显式检查状态码：用
$response->getStatusCode()判断是否为 2xx，否则静默失败 -
$response->toArray()比json_decode($response->getContent(), true)更安全——它会校验Content-Type: application/json，非 JSON 响应直接抛JsonException - GET 参数别写成
body，要用'query' => ['id' => 123]；POST 提交 JSON 别手动json_encode，直接用'json' => ['name' => 'foo']，客户端自动设 header 和序列化
异步请求不是加个 async 就能跑，得用 requestAsync() + Promise 等待
Symfony HttpClient 的异步能力依赖底层 cURL 的 multi 接口，不是协程，也不需要 Swoole。但它的“异步”只体现在并发发多个请求，不阻塞彼此；每个请求本身仍是同步完成的。
常见错误现象：写了 requestAsync() 却没 Promise::wait() 或 then()，结果程序退出前 Promise 还没 resolve，响应丢失。
- 必须用
Symfony\Contracts\HttpClient\ChunkInterface或Promise工具（如Promise\all()）来收集结果 - 不要在控制器里直接
Promise::wait()—— 它会阻塞整个请求生命周期，和同步没区别；适合用在命令行任务或后台 worker 中 -
requestAsync()返回的是Promise，不是Response；调用$promise->wait()才真正触发网络请求并返回Response
重试逻辑必须显式启用，RetryableHttpClient 不是开箱即用
默认的 HttpClient 实例完全不重试。即使配置了 max_retries，若没启用 retry_failed 选项，重试策略形同虚设。
常见错误现象：配了 max_retries => 3，但遇到 503 仍立刻失败；或者 POST 请求被重复提交三次——因为没意识到非幂等方法默认被跳过。
- 必须用
RetryableHttpClient包装原始客户端，且构造时传入的选项中要包含'retry_failed' => true -
'http_codes'必须显式列出要重试的状态码（如[500, 502, 503, 504, 429]），4xx 默认不重试 - POST/PUT/DELETE 默认不重试；如需重试，得确保服务端支持幂等（比如带
Idempotency-Keyheader），并在配置中允许（'retry_failed' => true已隐含支持，但语义上仍需服务端配合）
“发送即忘”在 HTTP 层面根本不存在，别在请求生命周期里硬扛
所谓 fire-and-forget，本质是把非关键通知（如埋点、告警、日志上报）从主请求流中剥离。任何调用 $httpClient->request() 的代码，无论是否读取响应，都会阻塞当前 PHP 进程直到连接关闭。
常见错误现象：给 Slack 发通知时加了个 1 秒超时，结果用户页面加载延迟整整 1 秒；或因目标服务宕机导致整个 API 响应超时。
- 真正的解法是用
Symfony Messenger把请求封装成消息，丢进队列（如 Doctrine、Redis、RabbitMQ），由独立的messenger:consume进程异步执行 - 不要试图用
timeout => 0.01“伪异步”——它只会把异常频率拉高，还要额外 catch 各种TransportExceptionInterface子类 - 如果连 Messenger 都不想引入，至少用
pcntl_fork()或exec('curl ... &')脱离主进程，但维护成本陡增，且不可靠
RetryableHttpClient 实例化时传对参数，且底层 HttpClient 自身启用了 retry_failed；漏掉任意一个，max_retries 就只是个摆设。 
