layui分页必须在jump回调中手动触发ajax请求加载数据，首次加载时通过first参数判断并调用loaddata，非首次则取obj.curr和obj.limit发请求；后端返回需含count和数据列表字段，前端须正确映射且limit与后端一致；表格更新需先清空再重写，搜索条件须透传并重置页码为1。
layui分页必须配合 jump 回调手动触发 Ajax
laypage 本身不自动发请求，它只负责渲染页码和响应点击。你得在 jump 函数里主动调用 Ajax 加载对应页的数据 —— 这是核心逻辑，漏掉就只会翻页不动数据。
常见错误现象：laypage.render() 执行后页码能点，但表格内容始终是第一页的旧数据；或者翻页时控制台没任何网络请求。
-
jump的第二个参数first是关键：首次加载时为true，此时应主动调用一次数据加载（比如loadData(1, 10)） - 非首次（
first === false）时，从obj.curr和obj.limit取当前页码和每页条数，再发请求 - 别在
jump外部单独调用一次loadData()，否则会导致第一页被加载两次
后端返回的数据结构要匹配前端分页参数
layui 不关心你后端用什么框架，但它依赖两个明确字段：count（总条数）和实际数据列表（如 data 或 content）。如果后端返回格式不一致，count: total 就会失效，页码总数算错。
使用场景：ThinkPHP 的 paginate() 默认返回 total、last_page、data；Spring Boot + Pageable 常返回 totalElements、content —— 你得按需映射。
- 前端必须用后端真实的总条数初始化
count，不能硬写死数字（比如count: 100） - 如果后端返回的是嵌套对象（如
{ code: 0, data: { total: 234, list: [...] } }），count要写成count: res.data.total -
limit值要和后端实际每页大小一致，否则页码计算错位（比如前端设limit: 15，后端却按 10 条分页）
表格 DOM 更新必须清空再重写，不能 append
很多人在 success 回调里用 $('tbody').append(...)，结果翻页后数据越叠越多。laypage 每次跳页都该重新渲染整页数据，不是追加。
容易踩的坑：用 jQuery 动态拼接 <tr> 时漏掉闭合标签，或没清空 <code>tbody 导致旧数据残留。
- 每次 Ajax 成功后，先执行
$('tbody').empty() - 再遍历
res.data（或你约定的数据字段），用$('<tr>...</tr>')构造并.appendTo('tbody') - 如果用原生 JS，推荐
innerHTML = htmlString，比 jQuery 链式构造更快
搜索条件必须透传到 jump 和初始加载中
带搜索的分页，关键词、时间范围等参数不能只存在表单里 —— 它们必须随页码一起发给后端，否则翻页后条件丢失，回到全量数据。
性能影响：每次跳页都带完整查询参数，后端才能正确分页过滤。漏传会导致第 2 页起数据错乱。
- 把搜索参数存为全局变量（如
let searchParams = { name: '', start: '', end: '' }） - 在
jump里构造请求时，合并参数：$.get('/api/list', Object.assign({ page: obj.curr, limit: obj.limit }, searchParams), ...) - 搜索按钮点击后，先更新
searchParams，再调用laypage.jump(1)强制回到第一页
curr: 1 就直接调 jump，导致页码显示还在第 5 页，但数据却是第 1 页的 —— 表象是“搜完翻页错乱”，根源是页码状态和数据状态没对齐。
