table.reload() 必须显式传 page.curr 否则默认跳第 1 页；应于 done 回调实时更新 currPage，禁用 DOM 读取页码；搜索保留页码，重置清为 1；删除后 reload 需用操作前页码。
table.reload() 必须显式传 page.curr，否则默认跳第 1 页
layui 的 table.reload() 不会自动继承当前页码，它本质是“新请求 + 新分页状态”，不传 page 配置时，curr 就是 1。这是最常被忽略的底层逻辑——不是 bug，是设计如此。
- 错误写法：
table.reload('demoId', { where: { keyword: 'xxx' } })→ 每次都回首页 - 正确写法：
table.reload('demoId', { page: { curr: window.currPage }, where: { keyword: 'xxx' } }) -
window.currPage必须在done回调里实时更新，不能只初始化一次
从 DOM 中读取当前页码？慎用 $(".layui-laypage-em").next().html()
网上流传的靠 jQuery 抓页码元素的方式（比如 $(".layui-laypage-em").next().html()）看似简单，但极易失效：
- 页面未渲染完成时执行，返回
undefined或空字符串，导致重载失败或跳首页 - Layui v2.8+ 启用虚拟滚动或自定义分页模板后，DOM 结构可能变化，选择器直接失灵
- 多表格共存时，若没加唯一 class 或 ID 限定范围，会读错其他表格的页码
- 更稳的做法：始终以
done回调参数curr为准，它是服务端真实返回的当前页，不受 UI 渲染干扰
搜索/重置场景下，页码要不要清空？看用户意图
不是所有重载都要保留页码。典型矛盾点在于「搜索」和「重置」行为：
- 用户点击「搜索」：应保留原页码（比如在第 5 页搜关键词，结果仍显示第 5 页数据）
- 用户点击「重置」或清空所有条件：应重置
curr为 1，并清除缓存（如localStorage.removeItem('tablePage')） - 若用
localStorage持久化页码，记得把搜索条件哈希值也存进去，避免条件变了还强行跳旧页（例如上次搜 “张三” 在第 3 页，这次搜 “李四” 却还跳第 3 页，结果为空）
删除/编辑后刷新表格，别漏掉异步时机控制
在行工具栏（toolbar）里触发删除、编辑等操作后调用 reload()，容易因 AJAX 响应顺序出问题：
- 删完立刻
reload()，但服务端还没删完，新请求可能查出刚删的数据，造成“幻读” - 应在
success回调里 reload，且确保传入的是**操作前记录的页码**（不是 DOM 里此刻显示的，因为删一行后当前页可能已不足一页，页码显示会自动调整） - 示例关键点：
var currBeforeDel = window.currPage; $.ajax({ url: '/user/' + id, method: 'DELETE', success: () => table.reload('userTable', { page: { curr: currBeforeDel } }) });
currPage 全局变量一劳永逸。 
