Symfony 2 已停止维护，当前应使用 Symfony 3.4+ 或更高版本；手动 new GuzzleClient 导致无法容器管理、硬编码依赖且绕过 Symfony HttpClient 抽象层，除非明确需要 Guzzle 中间件链或 SDK 强依赖，否则推荐直接使用 Symfony 自带的 HttpClient。
Symfony 2 已停止维护（EOL），官方自 2016 年起不再提供安全更新。你实际用的极大概率是 Symfony 3.4+ 或更高版本（比如 Symfony 6.x），但误写成了 “Symfony2”。直接按 Symfony 2 的方式配 Guzzle 不仅过时，还会踩一堆兼容性坑——比如旧版 Guzzle 5/6 与现代 PHP 版本、autoload 规则、服务容器语法全不匹配。
别硬套老教程。下面说清 现在该怎么做，以及为什么不能照搬“Symfony2 + Guzzle”那一套。
为什么不要在 Symfony 2 风格下手动 new GuzzleClient
你看到的“new GuzzleHttp\Client()”写法，在 Symfony 2 时代确实常见，但它带来三个硬伤：
- 无法被服务容器管理 → 无法打桩测试、无法复用连接池、无法统一配置超时/重试
- 硬编码依赖 → 比如把
base_uri写死在控制器里，换环境就得改代码 - 绕过 Symfony 的 HTTP 客户端抽象层 → Symfony 4.3+ 自带
Symfony\Component\HttpClient\HttpClient，轻量、默认开箱即用，Guzzle 反而成了冗余依赖
除非你明确需要 Guzzle 的中间件链（比如自定义 OAuth2 handler、日志注入到每个请求头）、或对接一个强制要求 Guzzle 特定版本的 SDK，否则没必要引入。
调用百度PaddleOCR‑VL大模型API，支持PDF、Word、PPT、图片等多格式文档解析，精准识别印刷体、手写体、表格、公式、图表、印章等复杂元素，支持100+语言，可处理不规则布局和跨页长文档。触发词：文档解析、VLM解析、大模型OCR、PaddleOCR、多模态文档、手写识别、公式识别、复杂版面。
如果真要装 Guzzle，怎么配才不翻车
假设你已确认必须用 Guzzle（比如第三方 SDK 强依赖 GuzzleHttp\Psr7），那安装和注册必须符合当前 Symfony 主流做法：
- 运行
composer require guzzlehttp/guzzle（它会自动适配 PHP 8.2+ 和 PSR-18 兼容） - 在
config/services.yaml中声明服务（别再写parameters.yml）：services: App\Service\BaiduApiClient: arguments: $client: '@http_client' # 优先复用 Symfony 自带 client # 或：$client: '@GuzzleHttp\Client'（需额外绑定，见下条） GuzzleHttp\Client: bind: $config: { timeout: 5.0, verify: true } calls: - method: 'withOptions' arguments: [ { timeout: 5.0, http_errors: false } ] - 注意：Guzzle 的
verify默认为true，但百度 API（https://api.baidu.com）部分子域证书可能不规范，若报cURL error 60: SSL certificate problem，临时可设verify: false（仅限开发），生产环境必须用系统 CA 或指定cafile
$response->getBody()->getContents() 是最常踩的解析坑
很多人调百度 API 后拿到空响应或乱码，问题不在 URL，而在解析方式。百度返回的通常是 UTF-8 JSON，但 Guzzle 的 getBody() 返回的是 Psr\Http\Message\StreamInterface，直接 echo 或 json_decode($stream) 会失败：
- 错误写法：
json_decode($response->getBody(), true)→ 报json_decode() expects parameter 1 to be string - 正确写法：
json_decode($response->getBody()->getContents(), true)，或更稳：json_decode((string) $response->getBody(), true) - 但更推荐统一用
$response->toArray()（如果你用的是 Symfony HttpClient）；Guzzle 用户可封装一层：function safeJsonDecode($response) { $content = (string) $response->getBody(); return json_last_error() === JSON_ERROR_NONE ? json_decode($content, true) : ['error' => 'Invalid JSON', 'raw' => $content]; }
百度 API 的真实请求注意事项
百度开放平台（如短网址、OCR、翻译）普遍要求 access_token，且 token 有 30 天有效期，不是静态 key。这意味着：
- 不能把 token 硬写进配置 —— 必须动态获取并缓存（用
cache.app或 Redis） - 请求前要先调
https://aip.baidubce.com/oauth/2.0/token换 token，再拿 token 调业务接口 - 百度返回的错误不是标准 RFC 7807，比如鉴权失败时返回
401但 body 是{"error":"invalid_client","error_description":"unknown client id"}，不能只靠状态码判断 - 务必检查响应头：
$response->getHeaders()['content-type'][0]—— 百度某些接口出错时会返回text/html（比如 503 页面），此时json_decode必炸
真正麻烦的从来不是“怎么发请求”，而是“怎么让请求在 token 过期、网络抖动、百度返回 HTML 错误页、PHP 升级后依然稳定跑下去”。把这些逻辑塞进一个可测、可换、可监控的 Service 里，比纠结用 Guzzle 还是 HttpClient 重要得多。
