table.reload() 必须显式传 page: { curr: 1 }，否则页码不重置，后端仍按旧页码查询；常见错误包括只改 where、硬塞 pageNum: 1、漏传 limit；正确写法需同时传 where、page、limit 和 table ID；并发搜索需节流防覆盖；page.curr 与后端字段名解耦，不可替换为 pageNum: 1；DOM 页码文案依赖 curr 状态，不传则不更新。
table.reload() 必须显式传 page: { curr: 1 }
不加这一行，就等于没告诉 layui “我要回第一页”——它会默认沿用当前页码（比如你在第 5 页点搜索，后端照样收到 page=5），结果只查第 5 页的新条件数据，前 4 页直接丢掉。
常见错误包括：
- 只改
where，以为带了搜索条件就会重置页码 - 在
where里硬塞pageNum: 1或page: 1，Layui 完全不识别 - 漏传
limit，导致分页器显示错乱，甚至自动 fallback 到默认 limit（通常是 30）
正确写法要四个参数都到位：
table.reload('userTable', {
where: data.field,
page: { curr: 1 },
limit: 10,
// 表格 ID 必须和 render 时一致
});
多次点击搜索按钮导致页码“跳空”
用户手快连点，table.reload() 并发执行，后一次可能没带 page: { curr: 1 }，就把前一次的页码设置覆盖掉了。
稳妥做法是封装函数 + 节流：
- 用一个布尔变量（如
isSearching）锁住按钮，请求开始设为true，done回调里再设回false - 或者用
setTimeout简单防抖（如 500ms 内禁止重复触发） - 别把 reload 逻辑直接堆在
form.on('submit')里，容易漏参数、难维护
自定义 request.pageName 不影响 page.curr 的写法
哪怕你后端要的是 pageNum 字段，前端控制页码仍然只能靠 page: { curr: 1 }。Layui 的 page.curr 是纯前端状态，和后端字段名完全解耦。
例如配置了：
request: {
pageName: 'pageNum',
limitName: 'pageSize'
}
reload 时仍要写：
page: { curr: 1 } // 不是 pageNum: 1，也不是 page: 1
否则后端收不到 pageNum=1，前端也卡在旧页码。
DOM 上的页码文案不会自动更新
表格下方显示的 “当前第 5 页” 文字，是由 Layui 内部 page.curr 驱动的。你不传 page: { curr: 1 }，它就一直显示 “第 5 页”，哪怕数据已经变了——这不是渲染延迟，是状态根本没变。
别去手动改 .layui-table-page em 里的文本，下一次翻页或 reload 会被覆盖；也别指望 table.render() 重绘能解决，那是初始化用的。
唯一可靠路径：每次搜索动作，都走 table.reload() + 显式 page: { curr: 1 }。少这一行，用户就会以为搜不到结果，其实只是停在空的下一页。
