要实现百度风格分页，需配置layout:['first','prev','page','next','last','skip']、groups:5（或7），配合jump回调重载数据、后端返回真实count与limits匹配，并覆盖css调整跳转框和高亮样式。
laypage 的 layout 配置决定分页结构
layui 默认只显示「上一页」「页码」「下一页」，要实现百度那种「首页、尾页、省略号、当前页居中」的效果，关键不是改 CSS，而是调整 layout 和配套参数。默认值 ['prev','page','next'] 不够用，必须显式加入 'first'、'last'、'skip'（跳转）和控制页码范围的 groups。
常见错误是只改 theme 或硬塞 HTML，结果页码错位、点击无效——本质是结构没配对。
-
layout: ['first', 'prev', 'page', 'next', 'last', 'skip']是基础组合，缺一不可 -
groups: 5控制连续显示的页码数（如当前页为 10，则显示 8-12），百度风格通常设为5或7 -
jump回调里必须手动触发数据重载，否则点击页码不刷新内容
prev/next/first/last 文本支持 HTML，但需注意转义
百度分页的「‹」和「›」箭头、文字加粗、图标替换，靠的是 prev、next、first、last 参数直接填 HTML 字符串。但浏览器会解析标签，所以引号、尖括号要小心。
比如写 prev: '<i class="layui-icon"></i> 上一页' 看似合理，实际可能被双层转义导致图标不显示。
调用百度PaddleOCR‑VL大模型API，支持PDF、Word、PPT、图片等多格式文档解析，精准识别印刷体、手写体、表格、公式、图表、印章等复杂元素，支持100+语言，可处理不规则布局和跨页长文档。触发词：文档解析、VLM解析、大模型OCR、PaddleOCR、多模态文档、手写识别、公式识别、复杂版面。
- 推荐用 Unicode 字符替代图标：
prev: '‹ 上一页'、next: '下一页 ›' - 加粗文字可用
first: '<strong>首页</strong>'，但确保外层没开启 XSS 过滤 - 若后端返回的 JSON 被自动转义（如 PHP 的
json_encode()），前端需先decodeURIComponent()再传给laypage.render()
跳转输入框和页码高亮需要额外 CSS 微调
百度分页的「跳至第 X 页」输入框和当前页高亮背景色，laypage 原生支持 'skip'，但样式完全依赖 layui 默认主题。想匹配百度灰蓝主色、圆角、hover 效果，必须覆盖 CSS。
容易忽略的是：laypage 渲染后生成的 DOM 结构固定，.layui-laypage-skip input 是输入框，.layui-laypage-curr 是当前页容器，但它的子元素 .layui-laypage-em 才是高亮背景块。
- 当前页高亮：重写
.layui-laypage-curr .layui-laypage-em的 background 和 color - 跳转按钮对齐：给
.layui-laypage-skip加display: inline-flex; align-items: center; - 输入框宽度：默认太窄，加
.layui-laypage-skip input { width: 50px; }
数据量大时 groups 和 limits 要配合后端分页逻辑
百度分页能快速跳转到任意页，前提是后端支持按 page 和 limit 返回对应数据。laypage 本身不处理数据，只负责 UI 和参数传递。如果前端强行用 parseData 做全量数据分页，groups 设再大也没意义——页面卡死在第 50 页加载时。
典型坑是：把 count 设成假数据（比如写死 10000），但后端实际只返回前 100 条，导致页码显示有 1000 页，点到第 101 页就空白。
-
count必须是后端真实总条数，不能估算 -
limits: [10, 20, 50, 100]要和后端支持的每页条数严格一致，否则选 50 却返回 10 条，UI 错乱 - 跳转输入框提交后，
jump回调里的obj.curr是用户输的页码，必须校验是否 ≤Math.ceil(count / limit)，否则请求越界
jump 回调里没重发请求，或者后端没校验 page 参数合法性——点「第 999 页」直接 500，UI 却还在转圈。
