layui无刷新分页本质是区分前端与后端模式：前端模式需删url、传全量data、显式配置page对象并手动切片重render；后端模式仅配url和page:true，由服务端返回分页数据。
layui 本身没有“无刷新分页”这个独立概念——它所有分页都是无刷新的，关键在于你用的是前端数据模式还是后端接口模式。只要不跳转页面、不 reload 整个 window，就属于无刷新；真正要解决的，是「怎么让分页切换时不发多余请求、不重绘整页、不丢状态」。
table.render() 配了 url 却还手动切片？别混用 data 和 url
这是最常导致“看似无刷新，实则翻页卡顿或数据错乱”的根源。layui table 在有 url 时会自动走 AJAX 请求，并忽略你传的 data 数组；反之，一旦写了 data，url 就会被静默丢弃。
- 后端分页（推荐用于 > 500 条数据）：只配
url+page: true，删掉data字段，让 layui 自动拼参（page和limit）并渲染返回的data - 前端分页（适合 ≤ 5000 条已加载数据）：必须删掉
url，只传data: allData，再显式配置page对象（不能只写page: true），且每次翻页都要重新调table.render()或table.reload()并传新切片 - 混用后果：表格只显示第一页、点击页码无反应、控制台报
Cannot read property 'length' of undefined（因为 data 被忽略，内部取不到数据）
laypage 单独用时 jump 回调重复触发？靠 first 参数拦截首次渲染
很多人把 laypage.render() 和自己的数据加载逻辑直接写在 jump 里，结果第一页被拉两次：一次是 render 初始化自动触发，一次是你手动调的。这不是 bug，是设计行为。
-
jump回调必带first参数：if (first) return是安全起点 - 真实数据加载逻辑应放在
if (!first)分支内，比如发 AJAX 或从本地数组切片 -
obj.curr和obj.limit是当前有效值，直接用于请求参数，别硬编码page=1 - 搜索条件等变量建议闭包进 jump 函数，避免从全局读取时值已过期
table.reload() 后分页器错位或空白？必须同步重置 page 配置
reload 不是“局部更新”，它会重建整个表格实例。如果你只传 data，它会沿用旧的 page.curr，而新数据总条数可能变少，导致当前页码超出范围，表格就空了。
- 正确 reload 前端分页数据：
table.reload('tableId', { data: newData, page: { curr: 1 } }) - 必须指定
id（初始化时加id: 'userTable'），否则 reload 找不到目标实例 - 如果只是改 limit（比如用户选“每页 20 条”），需同时传
page: { curr: 1, limit: 20 }，否则页码仍停留在原位置，但数据量已变 - 不要在 reload 外部维护 table 实例再反复调 reload —— 它对纯前端 data 模式支持不稳定，容易丢
count
真正难的不是写几行 render 或 jump，而是想清楚：这页数据到底该由谁算？前端切片还是后端查库？搜索排序是前端 filter 还是后端 SQL？这两个决策点一旦错位，后面所有 reload、done、where 都会变成补丁叠补丁。先定数据流，再套组件，比反过来试错快得多。
