直接监听 input 会因高频触发导致请求堆积、结果错乱；需用 setTimeout 防抖（清旧定时器+设新）、重置页码、处理空值、兼顾移动端 enter 和输入法兼容性。
为什么直接监听 input 会疯狂触发请求
Layui 的 table.render() 默认不带防抖，只要用户在搜索框里每敲一个字，如果绑了 input 或 keyup 事件并立刻调用 table.reload()，就会发一次请求。网速慢或后端响应慢时，页面卡顿、请求堆积、结果错乱（比如后发的请求先返回）全都会出现。
常见错误现象包括：
- 搜索“abc”，却看到“a”或“ab”的结果残留
- 连续输入时控制台刷出一堆 200 请求，但表格只闪一下
- 后端日志里同一秒内收到 5 条几乎一样的查询
根本原因是没切断高频触发链。Layui 表格本身不处理前端节流逻辑，得自己加一层“缓冲”。
用 setTimeout 实现最简防抖（推荐新手） 核心就是：每次输入，先清掉上一次定时器，再设一个新的。只有用户停顿够久（比如 300ms），才真正执行搜索。
使用场景：搜索框是普通 ，绑定在 Layui 表格外；或者用 table.render() 的 done 回调里动态绑定。
实操建议：
- 不要用
debounce工具函数封装（除非项目已引入 lodash），原生setTimeout更轻量、无依赖 - 定时器变量必须挂载在外部作用域（比如全局或闭包），否则每次事件都新建一个，清不掉
- 停顿阈值设 300ms 是平衡体验和响应速度的常见值，低于 200ms 用户感觉不到延迟，高于 500ms 显得卡顿
let searchTimer = null;
document.getElementById('searchInput').addEventListener('input', function() {
clearTimeout(searchTimer);
searchTimer = setTimeout(() => {
const keyword = this.value.trim();
layui.table.reload('myTable', {
where: { keyword }
});
}, 300);
});
reload 时注意重置页码和避免重复加载table.reload() 默认保留当前页码，但用户搜新词时，通常希望回到第一页。不手动重置，就可能出现“搜‘订单’只显示第 3 页的结果”，而第 1 页其实有更匹配的数据。
另一个坑是：如果搜索内容为空（keyword === ''），要不要 reload？多数情况应该清空表格或恢复原始数据，而不是发一个空参请求——后端可能没做空值兼容，直接 500 或返回全部数据。
参数差异和注意事项：
- 必须显式传
page: { curr: 1 }，否则页码不变 -
where中的字段名要和后端约定一致，比如后端接收q而不是keyword，这里就得改 - 如果表格启用了
url而非data，reload 会重新走 Ajax，但不会自动带上 headers 或 contentType，如有鉴权头需在request或parseData里补
移动端输入法回车键触发时机不对怎么办
在 iOS Safari 或部分安卓输入法下，用户点键盘“搜索”按钮，input 事件可能不触发，或者比 change 晚。结果就是敲完按搜索，没反应。
这不是 Layui 的 bug，是浏览器对虚拟键盘事件的支持差异。真实使用中，不能只靠 input。
解决方案：
- 同时监听
input和change，但change只在失焦时触发，不适合实时搜索 - 更稳妥的是加一个搜索按钮（
），点击时主动触发 reload，绕过输入法事件缺陷 - 若必须支持回车，监听
keydown并判断e.key === 'Enter'，但要注意防止表单默认提交
性能影响很小，但兼容性差的点容易被忽略：iOS 上 input 对中文拼音候选词的触发也不稳定，比如打“zhong”，选“中”字时才发一次事件，中间过程完全捕获不到。
防抖本身不难，难的是把输入事件、reload 时机、页码状态、空值处理、移动端适配这几件事串成一条不掉链子的线。漏掉任意一环，用户就会觉得“这搜索怎么时灵时不灵”。
