百度API响应慢的主因是Symfony2开发环境配置不当：appdev.php全量加载容器、同步日志I/O、未缓存DI元数据及模板编译等，导致请求卡顿3秒以上；应改用app.php生产入口、轻量HTTP客户端、禁用序列化器注解扫描并优化JSON解析。
不是百度API本身慢，而是 Symfony2 默认的 HTTP 客户端配置和环境切换没对齐真实使用场景。开发环境下 appdev.php 入口会启用完整调试栈、日志记录和模板重编译，哪怕你只是发个 curl 请求，整个容器也得全量加载——这才是拖慢百度搜索 API 响应的主因。
为什么用 appdev.php 调百度 API 会卡顿 3 秒以上
开发环境默认开启大量非必要服务：调试栏、实时模板编译、冗余日志通道、未缓存的 DI 容器元数据扫描。这些在页面渲染时合理，但在调用外部 API 时纯属负担。
-
appdev.php会强制启用debug: true，导致所有日志写入var/log/dev.log（同步 I/O 阻塞） - HTTP 客户端（如
GuzzleHttp\Client）若未显式禁用debug模式，会记录完整请求/响应体到内存，再由 Symfony 日志系统序列化输出 - 百度 API 返回 JSON 后，
serializer组件若未预热或未关闭enable_annotations: false，会反复反射解析类结构 - 开发环境下
cache.adapter.filesystem默认不启用，导致每次请求都重新解析路由、验证器、服务定义
如何让百度 API 请求走生产级路径
核心思路是：绕过开发环境的“全量加载”，但又不牺牲本地调试能力。关键不在换客户端，而在控制容器加载粒度。
百度文档解析vlm-parser
下载
调用百度PaddleOCR‑VL大模型API，支持PDF、Word、PPT、图片等多格式文档解析，精准识别印刷体、手写体、表格、公式、图表、印章等复杂元素，支持100+语言，可处理不规则布局和跨页长文档。触发词：文档解析、VLM解析、大模型OCR、PaddleOCR、多模态文档、手写识别、公式识别、复杂版面。
- 用
app.php入口发起 API 请求（例如/app.php/api/baidu-search），确保运行在prod环境 - 在控制器中显式创建轻量级 HTTP 客户端，避免依赖
http_client服务（它会拉起整个HttpClient栈）：$client = new \GuzzleHttp\Client(['timeout' => 5, 'verify' => false]);
- 禁用序列化器的注解扫描：
framework: serializer: enable_annotations: false - 确保百度 API 的响应头包含
Cache-Control: public, max-age=300，并在config/packages/prod/cache.yaml中启用响应缓存
百度搜索 API 的响应体解析陷阱
百度返回的 JSON 字段名常含中文或下划线（如 "result_num"、"百度快照"），直接映射到 PHP 属性会触发大量 property_exists() 和 ReflectionClass 调用，尤其在 dev 环境下无缓存时明显。
- 不要用
serializer->deserialize($json, Result::class, 'json')直接反序列化，改用原生json_decode($json, true)+ 手动提取关键字段 - 若必须用 Serializer，提前生成映射缓存：
php bin/console cache:warmup --env=prod
- 避免在循环中反复调用
$serializer->normalize()—— 百度 API 响应通常含数组列表，一次 normalize 整个数组比逐个处理快 3–5 倍 - 百度返回的
"errno"字段为字符串（如"0"），PHP 类型判断需用=== '0'，而非== 0，否则触发隐式转换+额外类型检查
真正卡住的从来不是百度服务器，而是你本地容器里那个没关掉 debug 日志的 Monolog\Handler\StreamHandler，还有每次请求都重扫一遍 src/ 目录的自动加载器。把环境切对、客户端拎出来、序列化器关注解——三步做完，90% 的“百度 API 慢”问题就消失了。
