table.filter()只搜当前页是因为其设计定位是列级轻量筛选，仅对已渲染DOM的当前页数据匹配，不访问table.cache；解决需关闭分页或手动遍历cache后reload。
table.filter() 为什么只搜当前页，不搜全量数据
因为 table.filter() 是 layui 原生设计的「列级轻量筛选」，它只对已渲染到 DOM 的当前页数据做 includes() 匹配，不访问 table.cache['id']。哪怕你初始化时传了完整 data 数组，只要开启了分页（page: true），它就默认只筛当前页 —— 这不是 bug，是它的定位：快速响应单页微调，不是全文搜索。
常见错误现象：table.filter('userTable') 输完关键词表格没变化，或只变了几行；查控制台发现 table.cache['userTable'] 里明明有 1000 条，但 filter 后还是空。
解决方向只有两个：
- 关掉分页（
page: false），让所有数据进缓存，再用table.filter()—— 仅适合 ≤ 500 条的静态小表 - 放弃
table.filter()，直接遍历table.cache['id']手动过滤，再table.reload()—— 这才是多字段全文搜的正路
如何安全遍历 table.cache 实现多字段模糊匹配
核心是别直接读 DOM 或依赖 templet 渲染后的文本，而是从缓存对象取原始字段值，统一转成字符串再判断。否则遇到 null、undefined、数字、日期等类型会报错或漏匹配。
示例逻辑（关键步骤）：
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 } // 必须重置页码
});
- 不要用
innerHTML或textContent反向提取，容易因格式/空格/换行丢失匹配 - 字段名要和
cols配置中field一致，比如后端返回user_name，但你配置了field: 'username'，那缓存里就是username字段 - 如果字段含嵌套对象（如
user.profile.name），table.cache默认不展开，需提前在parseData或后端做扁平化
搜索框绑定 reload 时必须注意的三件事
很多人写了搜索框却没效果，问题往往出在事件绑定和参数细节上。
- 监听必须显式绑定，比如
$('#searchBtn').on('click', ...)或form.on('submit(filter)', ...)，不能只放个<input>就指望自动联动 -
where必须是对象，不是字符串：where: { keyword: val }✅，where: 'keyword=' + val❌ - 每次
reload都要带page: { curr: 1 }，否则可能继续在第 5 页搜，结果为空，用户误以为“没搜到” - 空值处理要明确：
''和null可以传，但undefined会被 layui 跳过该字段，导致条件丢失
多字段拼音搜索只能靠后端实现
前端做拼音转换（比如用 pinyin-pro）在万级数据下必然卡死，且分页状态下本地过滤会导致漏查 —— table.search 本质只是触发 reload 并传参，它不会拦截输入、也不会预处理数据。
真正可靠的方案是服务端分页 + 后端拼音匹配：
- 后端建冗余拼音字段，如
name_pinyin = "zhangsan"、name_py_first = "zs" - 查询时用
WHERE name_pinyin LIKE '%zs%'，注意用预编译参数防 SQL 注入 - 前端只负责原样传关键词：
where: { keyword: $('#searchInput').val().trim() } - 多个字段都要拼音搜索（如姓名 + 城市），后端应分别对
name_pinyin和city_pinyin做OR匹配
最容易被忽略的是：后端必须对输入做 trim()，否则用户粘贴带空格的 “ 杭州 ” 就匹配不到；Layui 不会帮你清洗。
