搜索提交时必须显式重置 page.curr 为 1，因 table.reload() 默认沿用当前页码；需在 reload 中传入 page: { curr: 1 }，不可通过 where 传 pageNum 或 page；自定义参数名不影响 page.curr 前端控制逻辑。
搜索提交时必须显式重置 page.curr
默认情况下，table.reload() 会沿用当前页码（比如你在第5页点搜索，后端仍收到 page=5），导致查不到数据或返回空。这不是 bug，是 layui 的设计逻辑——它把分页状态视为“用户浏览上下文”的一部分，不会自动打断。
实操建议：
- 每次搜索都强制加
page: { curr: 1 }，哪怕你只想“带条件查当前页”，也得先回到第一页再翻； - 不要在
where里手动塞page: 1或pageNum: 1，Layui 不认这个，只认page.curr； - 如果用了自定义分页参数名（如
pageName: "pageNum"），page.curr依然有效，它控制的是前端行为，和后端字段名解耦。
done 回调里存页码 ≠ 搜索时自动恢复
很多人以为只要在 done 里记下 curr，搜索时就能“智能续上”，其实不是。Layui 不会主动读取你存的值，必须你自己在 reload 时显式传进去。
实操建议：
- 存页码推荐用
window.currentPage（轻量、无副作用），除非需要跨标签页/刷新保留才用localStorage； - 搜索时别直接写
curr: window.currentPage，要加兜底：curr: window.currentPage || 1，防止页面首次加载还没触发done就搜； - 注意：如果表格初始化失败（比如 URL 404），
done不会执行，window.currentPage就是undefined，没兜底就会报错。
删完最后一页数据，页面卡空？这不是搜索问题，是分页逻辑断层
比如当前在第3页，删光了这页所有数据，后端返回 count=28（总条数变少），但前端 curr 还是 3，而 28 条数据只够 2 页（limit=10），第3页自然没数据——表格就停在空白页。
实操建议：
- 这是典型“后端 count 更新了，但前端没同步跳页”的现象，和搜索无关，但常被误认为搜索 bug；
- 最稳妥的做法是在
done里判断：if (res.data.length === 0 && curr > 1) { table.reload(..., { page: { curr: curr - 1 } }); }； - 不建议直接改 Layui 源码（如 patch
pullData），升级时容易丢，维护成本高；同一套逻辑封装成函数复用更可控。
为什么不能靠隐藏 input 或表单 value 记页码？
有人把当前页写进 <input type="hidden" name="page">，然后在搜索时读它——这看似合理，但实际不可靠。因为 Layui 的分页控件点击、table.page() 调用、甚至某些 reload 场景，都不会自动更新这个 input 的值。
实操建议：
- 页码状态必须由 Layui 表格自身生命周期驱动（
done、page事件），不能靠 DOM 值桥接； - 如果真要用表单提交（非 AJAX），那就放弃
table.reload，改用完整页面跳转 + 后端分页，否则前后端状态极易脱钩； - 记住：Layui 表格的页码是内部状态，不是表单字段，混用两种范式是多数“搜索不回第一页”问题的根源。
真正难的不是写那行 page: { curr: 1 }，而是想清楚：你到底要“重置上下文”还是“延续浏览态”。前者就硬设 1，后者就得自己管好 curr 的存取时机——而 Layui 不替你做这个判断。
