Layui table列头筛选需手动实现：在cols中用templet渲染带下拉箭头的标题，监听header事件动态插入绝对定位筛选面板；筛选时基于originalData做前端filter并table.reload({data: filtered, page: {curr: 1}})，多条件联合校验避免嵌套filter。
layui table 怎么加列头筛选下拉框
直接在 cols 配置里给某列加 templet + 自定义筛选 ui，layui 原生不支持点击列头弹出筛选菜单，得自己挂事件、自己画 dom。
常见错误是直接写 filter: true —— 这个参数只对服务端排序有效，跟筛选完全无关；还有人误以为 toolbar: true 能联动列头筛选，其实 toolbar 是表格上方工具栏，和列头无关。
实操建议：
- 在
cols中对应列加title和field，再用templet渲染带下拉箭头的标题（比如加个▼或小图标） - 用
table.on('header(*)<table-id>', ...)</table-id>监听列头点击，拿到field后动态插入下拉筛选面板（绝对定位，覆盖在表头下方） - 筛选项数据建议提前缓存，别每次点都重查；如果是远程枚举，至少加防抖，避免频繁请求
- 注意 z-index 层级：下拉面板要高于
.layui-table-box的overflow: hidden，否则被截断
怎么让筛选结果实时影响表格数据（不刷新页面）
核心是调用 table.reload()，但不能直接传新数据——Layui 表格的数据源靠 url 或 data 控制，本地筛选必须走前端过滤逻辑。
典型场景：用户从下拉里选“状态=启用”，你得从原始数据里 filter 出匹配项，再把结果塞进 data 选项里 reload。
实操建议：
- 初始化时用
data加载全量数据（别用url），否则每次筛选都要发请求，体验卡顿 - 维护一个
originalData变量存原始数据，每次筛选都基于它做filter，避免嵌套过滤导致数据越筛越少 -
table.reload()时必须传page: { curr: 1 }，否则当前页码不变，可能显示空页 - 如果用了分页，筛选后记得手动重设
count，否则页码器不更新
多条件联合筛选怎么处理（比如日期范围 + 状态 + 关键词）
不是简单地把每个字段 filter 拼起来，而是要构造统一的校验函数，否则容易漏条件或逻辑错乱。
常见坑是用多个 if (val1) data = data.filter(...) 嵌套，结果前一个 filter 把数据改了，后一个 filter 在残缺数据上跑，最终结果不对。
实操建议：
- 所有筛选条件存在一个对象里，比如
{ status: 'enable', dateStart: '2024-01-01', keyword: 'test' } - 遍历原始数据时，用单次
filter+ 多条件判断：只有全部条件都满足（或为空则跳过该条件）才保留 - 日期范围要转成
Date对比，别用字符串直接>=，否则 '2024-10-1' > '2024-2-1' 会判错 - 关键词搜索建议用
includes()或正则，注意大小写：可统一转小写再比，避免'ABC'.includes('abc')返回 false
移动端适配和性能要注意什么
下拉筛选面板在手机上容易点不准、遮挡内容，而且全量数据一多，filter 就卡顿，特别是 IE 或低端安卓 WebView。
性能影响比想象中大：1w 条数据做 3 个字段联合 filter，老设备可能卡顿 500ms+，用户会觉得“点了没反应”。
实操建议：
- 移动端优先用
layer.open({ type: 1 })弹窗做筛选，比绝对定位更稳；关闭弹窗后才触发 reload - 数据量超 2000 条就加节流：用户停止输入/选择 300ms 后再执行 filter，避免边点边刷
- 用
Object.keys(filters).some(k => filters[k])快速判断是否有有效筛选条件，没条件就直接用原数据，省掉 filter 开销 - 别在
templet里写复杂逻辑，尤其是涉及 DOM 查询的，会拖慢渲染；筛选逻辑全收在 reload 前的纯函数里
page.curr 导致页码错位、以及原始数据被意外修改后无法还原。这些点不显眼，但一出问题就难定位。
