根本原因是table.reload()未重置页码，导致仍按原页码（如第2页）请求，而新搜索结果不足一页时后端返回空数组；必须显式传page: {curr: 1}才能真正从第1页重新分页。
点击搜索后查不到第2页数据，根本原因是 table.reload() 没重置页码，却仍按原页码（比如第2页）发起请求，而新搜索结果总数可能不足30条（假设每页15条），导致第2页无数据可返回——不是后端没查到，是前端压根没让后端查第1页。
为什么搜完跳到第2页就显示“无数据”
你当前在第2页，点搜索按钮，table.reload() 默认复用 page.curr = 2，发请求时带的是 page=2&limit=15；但新条件只匹配出10条数据，count=10，后端按规则返回空数组（因为第2页要取第16~30条），Layui 渲染后就是空白表格 + 分页栏显示“共10条，当前第2页”。用户以为搜错了，其实是卡在了无效页码上。
- 仅改
where不触发页码变更，page: 1或where: {page: 1}完全无效 -
table.config['xxx']?.page?.curr是当前页码，但 reload 时不传page字段，它就不会被读取 - 后端返回的
count正确也没用——页码错，数据就错位
必须显式传 page: {curr: 1} 才能真正从头查
这是唯一可靠方式。Layui 不会自动归零，必须明说“我要从第1页开始重新分页”。漏掉这一行，等于默认告诉后端：“请继续查第N页”，哪怕你刚清空了所有搜索条件。
- 写成
page: 1会静默失败，必须是对象{curr: 1} - 如果页面支持自定义每页条数（如用户切过
limit=20），limit也得一并传，否则可能回退到默认值（如10）导致分页错乱 - 示例：
table.reload('userTable', { where: data.field, page: {curr: 1}, limit: 10 });
多次点击搜索按钮会让问题更隐蔽
快速连点触发多个 reload()，后一个若没带 page: {curr: 1}，就会覆盖前一个的页码设置，导致视觉上“点了却没动”，或偶尔回第1页、偶尔卡在第2页——这不是随机 bug，是并发冲突。
- 别在
form.on('submit', ...)里直接写reload，容易漏参数、难节流 - 封装成函数，加 loading 状态锁住按钮（如
btn.prop('disabled', true)），500ms 内禁止重复提交 - DOM 上显示的“当前第2页”文案由 Layui 内部
page.curr驱动，只有page: {curr: 1}才能同步刷新它
最常被忽略的细节：哪怕搜索条件为空、哪怕用户就在第1页，每次调用 table.reload() 都得带上 page: {curr: 1}。少这一行，逻辑就断在服务端分页入口。
