layui分页必须配合Ajax实现异步加载，laypage.render()需传count（服务端返回总数）和jump回调，在jump中手动发请求、清空tbody、渲染新数据，并同步搜索条件与页码状态。
layui 分页必须配合 Ajax 才能实现真正的异步加载，否则 laypage 只是静态页码渲染，不触发数据请求。
laypage.render() 里必须传 count 和 jump 回调
count 是总条数，必须从服务端返回（不能写死），jump 是每次翻页时的执行入口——它不自动发请求，你得自己在 jump 里调用 Ajax。
-
count必须是数字类型，后端接口应返回类似{"count": 127, "data": [...]}的结构 -
jump函数的obj.curr是当前页码，obj.limit是每页条数，这两个要原样传给后端 - 首次渲染时
jump会默认执行一次，所以不用额外调用第一次加载 - 如果后端分页参数名不是
page和limit（比如叫curr、pageSize），要在 Ajax 请求中手动映射
jump 回调里必须手动发 Ajax 并更新 tbody
很多人以为 laypage 会自动绑定表格，其实它只管页码 DOM；数据填充、清空旧内容、插入新行全靠你写在 jump 里。
- 每次
jump执行前，先清空<tbody>，避免重复追加：$('tbody').empty() - Ajax 成功后，遍历
res.data，拼 HTML 或用 jQuery 动态创建<tr>插入tbody - 不要在
success外部操作 DOM，否则可能因异步时机错乱导致空白或重复 - 如果表格用了
layui.table渲染，就别手动拼tbody，改用table.reload()更稳妥
后端分页参数和前端 laypage.limit 不一致时容易出错
常见坑：后端要求 page=1 表示第一页，但 laypage 的 curr=1 也是第一页，看似一致，实际 offset 计算逻辑可能不同。
- 确认后端是否用
(curr - 1) * limit算起始位置；如果不是（比如直接用curr * limit），前端要调整传参 - 后端返回的
count必须是真实总数，不能是当前页数据长度，否则页码数量会错 - 如果后端分页依赖查询条件（如搜索关键词），
jump中每次请求都要把条件参数一并带上，否则翻页后条件丢失 - 注意缓存：Ajax 默认可能缓存 GET 请求，加
cache: false或用 POST 避免旧数据复用
搜索后重置分页状态必须手动触发
用户输完关键词点搜索，页码应回到第一页，且总条数要刷新——laypage 不会自动响应这个动作。
- 搜索按钮点击后，先保存搜索条件变量（如
let searchKey = $('#search').val()） - 调用
laypage.render()重新初始化，传入新count和初始curr: 1，同时确保jump内部使用最新searchKey - 更稳妥的做法是销毁旧实例：
laypageElem.data('laypage', null)（需 jQuery），再重新 render - 如果用
table.render()+page: true，搜索时直接table.reload({ where: { key: searchKey }, page: { curr: 1 } })更简洁
真正难的不是写几行 laypage.render()，而是让 count、curr、limit、offset、where 条件这五个值在前后端之间始终对得上；少一个同步环节，就会出现“页码显示 5 页，点第 3 页却加载第 1 页数据”这类问题。
