Symfony HttpClient轻量内置，推荐用HttpClient::create()发起请求，支持自动重试/超时/解压，$response->toArray()可直接转数组并自动抛异常，避免手动json_decode；非JSON响应需抽离解析逻辑，错误处理应统一封装而非散落各处。
直接用 Symfony\Component\HttpClient\HttpClient，别手写 cURL 或硬塞 Guzzle；它轻量、内置、自动处理重试/超时/编码，并且 $response->toArray() 能直接转 PHP 数组，省掉 json_decode() 和异常兜底。
怎么发请求：用 HttpClient::create() 而不是 new Client()
Symfony 4.3+ 自带 HTTP 客户端组件，无需额外装 Guzzle（除非你真需要它的中间件生态）。HttpClient::create() 返回的实例已预设合理的默认值：连接超时 5 秒、最大重试 1 次、自动解压 gzip、自动处理重定向（最多 5 次）。
- 不要手动 new
GuzzleHttp\Client，除非你明确需要 Guzzle 的 HandlerStack 或自定义中间件 - 避免在控制器里直接创建客户端实例——应封装为服务，方便复用、打桩测试、统一配置（如 base_uri、auth header）
- 若需设置全局 token，推荐在服务构造时注入，并用
withOptions()绑定到每次请求：$client->withOptions(['headers' => ['Authorization' => 'Bearer '.$this->token]])
怎么解析响应：优先用 $response->toArray()，别碰 getContent() + json_decode()
$response->toArray() 不仅自动判断 Content-Type 是否为 JSON，还会在非 2xx 状态码时抛出 ClientExceptionInterface 或 ServerExceptionInterface，比手动检查 $response->getStatusCode() 更可靠。
- 成功响应（200–299）：直接返回关联数组或索引数组，无需
json_decode($response->getContent(), true) - 失败响应（4xx/5xx）：默认不自动抛异常，需显式调用
$response->getContent()或$response->toArray()才触发；建议统一在 service 层调用toArray()并捕获异常 - 遇到
JSON_PARSE_ERROR？先确认 API 真返回了合法 JSON —— 有些接口在错误时返回 HTML 错误页，toArray()会直接炸，此时应先检查$response->getHeaders()['content-type'][0]
怎么处理非 JSON 响应：XML/CSV 要手动解析，但别在控制器里做
HttpClient 不提供 toXml() 或 toCsv() 方法。遇到 XML 或 CSV，解析逻辑必须抽离到独立方法或 DTO 类中，否则控制器会迅速变臃肿。
- XML：用
simplexml_load_string($response->getContent())得到SimpleXMLElement，再递归转数组（注意命名空间和属性需显式提取） - CSV：用
str_getcsv()行级解析，或更稳妥地用fgetcsv()配合临时 stream（防内存溢出） - 关键点：所有解析失败（如空内容、格式错乱）都应转为业务异常（如
ApiDataFormatException），而不是静默返回空数组
怎么统一错误响应：别在每个 service 方法里 try-catch
第三方 API 不稳定是常态。把重试、降级、熔断、日志这些横切逻辑堆在每个 getUsers() 或 postOrder() 里，等于主动给自己埋雷。
- 用装饰器模式包装 HttpClient 实例：例如
RetryableHttpClient在 5xx 时自动重试 2 次，CircuitBreakerHttpClient连续失败 5 次后快速失败 - 错误响应体要结构化：即使上游返回的是纯文本错误，你也应在 service 层统一包装成
['error' => 'upstream_unavailable', 'code' => 'EXT_503'] - 最易被忽略的一点：HTTP 状态码 ≠ 业务状态。比如支付接口返回 200 +
{"status":"failed"}，这种“假成功”必须在解析后二次校验，不能只看 statusCode
