laypage.render 的 groups 参数控制连续页码个数，默认为5，需手动调用并传入该值，同时 table 必须设 page: false 以避免冲突，且每次数据变更后须重新执行 laypage.render()。
laypage.render 的 groups 参数才是控制连续页码个数的关键
layui table 自身的 page 配置里没有 groups 字段，这个值由底层分页组件 laypage 控制，默认为 5（即最多连续显示 5 个页码，如 … 6 7 8 9 10 …）。想改成 3 或 7，必须绕过 table 自动分页，手动调用 laypage.render() 并显式传入 groups。
常见错误是直接在 table.render({ page: { ... } }) 里加 groups: 3 —— 这个字段会被忽略，毫无效果。
-
table.render()中必须设page: false，否则 table 和 laypage 两套分页逻辑会冲突，DOM 重复、事件错乱 -
count值不能为0或undefined，否则 laypage 退化为简版（只显示上/下一页），groups失效 - 每次数据变更（如搜索、筛选）后，若总条数变化，必须重新执行
laypage.render()，否则页码栏不刷新
手动接管分页时如何同步表格数据重载
禁用 table 自动分页后，翻页动作不再自动触发请求，需在 laypage.render() 的 jump 回调里调用 table.reload()，并把当前页码注入 where。
关键点在于：reload 必须传入完整的 page 配置（含 curr），否则页码状态不同步，可能始终卡在第一页。
-
table.reload('demo', { where: { page: obj.curr }, page: { curr: obj.curr } })——where传给后端，page.curr同步表格内部状态 - 如果表格没设
id（即 render 时没传id: 'demo'），只能用table.reload()全局重载，容易误触其他表格 - 不要在
done回调里直接调table.reload()，否则会形成无限循环（reload → done → reload…）
为什么改了 groups 却没生效
最常被忽略的是 table 默认分页未真正关闭。即使写了 page: false，若后续某次 table.reload() 没带 page: false，就会悄悄恢复自动分页，导致手动渲染的 laypage 被覆盖或失效。
- 检查 Network 面板：翻页时是否仍发出带
?page=2&limit=10的请求 —— 如果有，说明 table 自动分页还在运行 - 确认
laypage.render()的elem是独立容器（如id="pageDemo"），别和表格elem混用，否则 DOM 被 table 重绘时 laypage 节点丢失 -
groups只在非简版模式下生效，而简版触发条件除了count ≤ 0，还包括页面宽度不足（小屏下自动降级），此时无论设多少都无效
服务端分页下动态更新总条数的注意事项
前端分页靠 count 算页数，但服务端分页时，这个值来自接口响应。如果搜索后总数变了，但 laypage.render() 没重新执行，页码栏就还是旧的范围（比如搜出 12 条，却还显示 1–10 页）。
别指望 table.reload() 自动更新 laypage —— 它只管表格内容，不管分页 DOM。
- 每次请求成功后，在
done回调里取res.count（或你映射的response.countName），再调一次laypage.render() - 如果用
parseData提取count，确保返回结构是{ data: [...], count: 123 }，否则res.count为undefined - 避免在
jump回调里重复渲染 laypage —— 它只应在数据加载完成、拿到新count后执行一次
page: false 彻底关闭自动分页、laypage 的 groups 显式设置、以及每次数据变更后对 laypage 实例的重新渲染。漏掉任意一环，页码栏都会回到默认的 5 个连续数字。 
