layui table 的前端模糊搜索需手动遍历 table.cache 实现全量多字段匹配，因其原生 filter() 仅筛选当前页已渲染 DOM 行，不读取缓存数据；正确做法是获取 cacheData 后统一转字符串并忽略大小写比对，reload 时须重置 page.curr 并处理 null/undefined 等类型兼容性问题。
layui table 前端模糊搜索不是开个 search: true 就能直接多字段全文搜的，它默认只筛当前页、只匹配已渲染列、且不处理 null/数字/嵌套字段——真要搜全量数据并支持任意字段，必须绕过原生 table.filter()，手动遍历 table.cache 后 table.reload()。
为什么 table.filter() 搜不了全量数据
因为它是「列级轻量筛选」，只对当前页已插入 DOM 的 <tr> 做 <code>includes() 匹配，完全不读 table.cache['id']。哪怕你初始化时传了 1000 条数据，只要 page: true，它就只筛第 1 页那 10 条。
- 常见错误现象：
table.filter('userTable')输关键词没反应，或只变几行；查console.log(table.cache['userTable'])发现缓存里明明有数据 - 这不是 bug，是设计定位：响应单页微调，不是做全文搜索
- 想用它，只能关分页：
page: false，但仅适合 ≤500 条静态表，否则页面卡顿
怎么安全遍历 table.cache 实现多字段模糊匹配
核心是别碰 DOM 文本，直接从缓存对象取原始字段值，统一转字符串再判断。否则遇到 null、undefined、数字、日期会报错或漏匹配。
- 字段名必须和
cols中field一致，比如后端返回user_name，但你配置了field: 'username'，那缓存里就是username字段 - 嵌套字段（如
user.profile.name）不会自动展开，需提前在parseData或后端扁平化 - 示例逻辑（关键步骤）：
const cacheData = table.cache['userTable'] || [];
const keyword = $('#searchInput').val().trim();
if (!keyword) {
table.reload('userTable', { where: {} });
return;
}
const filtered = cacheData.filter(item => {
return Object.keys(item).some(key => {
const val = item[key];
// 转字符串并忽略大小写
return String(val || '').toLowerCase().includes(keyword.toLowerCase());
});
});
table.reload('userTable', {
data: filtered,
page: { curr: 1 } // 必须重置页码
});
搜索框绑定 reload 时必须注意的三件事
前端搜索不是加个 input 就完事，reload 行为若没控好，会导致空页、状态错乱、重复请求。
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“前端免费学习笔记（深入）”；
-
where必须是对象，不能是字符串：where: { keyword: $('#searchInput').val().trim() }✅ - 空值传
""或null，别传undefined，否则某些版本会跳过该字段 - 必须显式设置
page: { curr: 1 }，否则 reload 后仍停留在第 3 页搜，结果为空
最易被忽略的是字段类型兼容性——String(null) 是 "null"，String(undefined) 是 "undefined"，直接 includes 会误匹配；实际项目里得先 val == null ? '' : val 再转串。还有，如果表格启用了树形结构（tree）或复选框（checkbox），reload 后选中态和展开态都会丢失，得在 done 回调里手动恢复。
