百度API分页需手动解析page_no、page_size、total_num等字段，Symfony 2不兼容KnpPaginatorBundle；应逐页请求、及时释放内存、主动垃圾回收，并在Controller预处理数据后传入Twig手写分页逻辑。
百度API返回的分页数据通常不是标准REST风格，而是带page_no、page_size和total_num字段的自定义结构，Symfony 2（PHP 5.6+）环境下不能直接套用KnpPaginatorBundle——它依赖Symfony 3+的Request对象注入机制和现代组件契约，强行接入会触发ArgumentCountError或ClassNotFoundException。
手动解析百度API分页响应体
百度API（如百度地图、百度搜索资源平台等）多数返回JSON，但分页字段名不统一，常见组合是page_no、page_size、total或total_num，且无next_page_url。你得自己拼URL并控制循环边界。
- 先用
file_get_contents()或curl_exec()拿到原始响应，别用Symfony HttpClient（Symfony 2没这个组件） - 用
json_decode($content, true)转数组，立刻检查json_last_error()——百度偶尔返回HTML错误页（比如401时吐出登录跳转），json_decode会静默失败 - 从解码结果里提取
['data']或['result']作为主数据数组，再读['total_num']或['total']算总页数 - 注意：百度某些接口的
page_no从1开始，有些从0开始，必须看文档确认，否则第一页就漏数据
避免内存溢出的大批量遍历写法
百度API单页最多返回100条，但总数据可能上万。如果一次性拉完再array_merge()，PHP 5.6默认内存限制（128M）很快崩掉。
百度文档解析vlm-parser
下载
调用百度PaddleOCR‑VL大模型API，支持PDF、Word、PPT、图片等多格式文档解析，精准识别印刷体、手写体、表格、公式、图表、印章等复杂元素，支持100+语言，可处理不规则布局和跨页长文档。触发词：文档解析、VLM解析、大模型OCR、PaddleOCR、多模态文档、手写识别、公式识别、复杂版面。
- 用
for循环按页请求，每页处理完立刻unset()临时变量，别累积到一个大数组里 - 关键点：在循环体内用
gc_collect_cycles()主动触发垃圾回收，尤其处理图像URL或长文本字段时 - 不要用
Doctrine\ORM\EntityManager::persist()批量存——Symfony 2的Doctrine 2.4不支持bulkInsert，改用原生$connection->executeStatement()拼INSERT语句 - 加
sleep(0.1)防被限流；百度对未授权调用频次敏感，503响应里常带X-RateLimit-Remaining头，记得解析它
把百度分页结果喂给Twig时的坑
Symfony 2的Twig 1.x不支持pagination.currentPageNumber这类KnpPaginator语法，你得手写分页导航逻辑。
- Controller里把当前页、总页数、是否首页/尾页等信息塞进
$this->render('xxx.html.twig', [...])的第二个参数数组 - Twig模板里用
{% for i in 1..total_pages %}生成页码链接，URL参数用{{ app.request.get('q')|default('') }}透传搜索词，别漏了page_no以外的查询参数 - 禁止在Twig里调用
json_decode或file_get_contents——模板层不该发起HTTP请求，所有数据必须在Controller准备好 - 百度返回的
data可能是空数组或null，Twig里要用{% if data is defined and data|length > 0 %}判空，不能只写{% if data %}
百度API的total_num字段有时不准（尤其含缓存策略时），实际遍历时发现某页data为空却仍有下一页，得靠count($data) 双保险判断终止条件——这比硬算总页数可靠得多。
