table.reload() 不适用于本地实时搜索，因其默认触发服务端请求，而非前端内存过滤；正确做法是监听 input 事件、用 table.cache 或原始数据 filter 后重绘 tbody。
不能直接用 table.reload() 实现实时过滤本地数据——它会触发服务端请求，而本地数据过滤必须走前端内存遍历。
为什么 table.reload() 不适用于本地实时搜索
当你调用 table.reload() 时，Layui 默认会重新发起 AJAX 请求（哪怕你配置了 data 而非 url），除非显式指定 method: 'get' 且 url: null，但即便如此，它仍不走本地 filter 逻辑。真正的本地实时过滤，依赖的是 table.cache 和手动重绘。
- 常见错误现象：
table.reload('id', { where: {name: val} })对本地数据无效，表格空白或报错 - 根本原因：Layui 的
reload()设计目标是服务端重载，不是前端数组filter() - 性能影响：若强行用 reload 模拟本地搜索，每次输入都触发一次“假请求”，卡顿明显、无必要
正确做法：监听 input + 手动过滤 table.cache + 重绘 tbody
核心路径是：监听表头输入框的 input 事件 → 从 table.cache['yourTableId'] 取原始数据 → 按条件 filter() → 用 table.render({ data: filteredArray }) 或直接操作 DOM 重写 tbody。
- 必须在
done回调中绑定事件，确保表头 DOM 已就绪 - 推荐用
layui.$('input[name="username"]').on('input', fn)，而非keyup，避免中文输入法上屏延迟 - 过滤逻辑要兼容空值、正则模糊匹配（如
item.username?.includes(val)） - 不要调用
table.reload()，改用table.render({ elem: '#demo', data: filtered, cols: [...] })重绘整表（轻量数据）或仅替换tbody.innerHTML（大数据）
示例：三行关键代码完成本地实时搜索
假设表格 ID 是 userTable，用户名列字段为 username：
table.render({
elem: '#demo',
id: 'userTable',
data: originalData, // 必须是数组，不能是 url
cols: [[{field: 'username', title: '用户名'}]],
done: function(res, curr, count){
layui.$('input[name="username"]').on('input', function(){
const val = this.value.trim();
const filtered = originalData.filter(item =>
item.username?.toLowerCase().includes(val.toLowerCase())
);
// 重绘：只更新 tbody（推荐，快）
const trs = filtered.map(item =>
`<tr><td>${item.username}</td></tr>`
).join('');
layui.$('#demo').next('.layui-table-box').find('tbody').html(trs);
});
}
});
- 注意：
originalData必须在作用域内可访问，不能只靠table.cache—— 它可能被排序/分页修改过 - 如果列多、结构复杂，建议封装一个生成
<tr>的函数，避免字符串拼接出错 - 移动端需防抖（
setTimeout+clearTimeout），否则快速输入易卡死
容易被忽略的兼容性点
表头搜索框插入位置、样式隔离、输入法兼容这三点实际项目中最常翻车。
- 表头搜索框必须插在
.layui-table-header th .layui-table-cell内，否则 iOS Safari 下拉菜单会被裁切 - 不要用
form.render()初始化表头里的input，它会加多余 class 导致样式错乱 - 中文输入法下，
input事件在“上屏”后才触发，但部分安卓机型有延迟，建议加compositionstart/compositionend监听兜底
