大数据量表格筛选卡顿的根源是DOM遍历+文本提取+字符串匹配叠加触发Long Task，需用虚拟滚动、防抖、单次filter、CSS类控制显隐等策略协同优化。
大数据量下 filter() 遍历 DOM 就会卡
直接 document.querySelectorAll('tbody tr') 拿几千行，再对每行 cells[0].textContent.includes(keyword)，主线程会被 JS 占满，滚动和输入都掉帧。这不是代码写得不对，是浏览器渲染机制决定的：DOM 查询 + 文本提取 + 字符串匹配，三者叠加在单次事件中，很容易触发 Long Task。
实操建议：
• 用 documentFragment 批量操作节点，避免边遍历边改 style.display
• 列表容器加固定高度 + overflow-y: auto，只控制显隐，不增删节点
• 超过 2000 行，放弃纯前端筛选，改用虚拟滚动（如只渲染可视区域 20 行）
• 若必须保留全量数据，把原始数组缓存在 JS 变量里，filter 时只操作 JS 对象，最后批量更新 DOM
input 实时监听没防抖，打字就闪屏
用户还没输完，“张”刚敲出来，oninput 就立刻执行一次全量过滤，DOM 重绘一次；紧接着“三”进来，又来一次——两次结果不同，列表反复显隐，视觉上就是“闪”。更糟的是，中间某次过滤可能因空值或正则错误直接崩掉。
实操建议：
• 必须加防抖：用 setTimeout + clearTimeout，延迟 300ms 足够覆盖正常打字间隙
• 不要用 onchange：它只在失焦时触发，用户无法实时看到反馈
• 清空搜索框时，检查 event.inputType === 'deleteContentBackward' 或比对前后值，而不是只看当前 value 是否为空
• 移动端慎用 input[type="search"] 的默认行为，iOS 点清空按钮也会触发 input 事件，值为空字符串
多个筛选条件共用一个 filter()，别链式调用
写成 data.filter(a => a.name.includes(kw)).filter(b => b.status === s).filter(c => c.age > min)，表面逻辑清楚，实际要遍历三次数组、创建两个中间数组。1000 条数据 × 3 次遍历 = 3000 次循环 + 内存分配，性能损耗明显，且难以调试漏行问题。
实操建议：
• 所有条件收口到单个 filter() 回调里，用布尔表达式组合：arr.filter(item => (!kw || item.name.includes(kw)) && (!s || item.status === s) && (min === undefined || item.age > min))
• 每个条件默认为 true（即“不限制”），避免空输入导致整批数据被筛掉
• 多选状态类字段（如复选框组）用 new Set(selectedValues) 存，查的时候用 selectedSet.has(item.value)，比 Array.includes() 快
• 正则提前缓存：const reg = keyword ? new RegExp(keyword.replace(/[.*+?^${}()|[]\]/g, '\$&'), 'i') : null，避免每次构造
显隐控制别直接写 style.display
写 tr.style.display = 'none' 看似简单，但恢复时如果忘了记原始值（比如原来是 table-row 还是 flex），一设 '' 就错位；频繁读写 style.display 还会强制同步 Layout，尤其在表格里，卡顿感更强。
立即学习“前端免费学习笔记（深入）”；
实操建议：
• 统一用 CSS 类控制显隐，例如定义 .hidden { display: none !important; }
• 切换时只操作 el.classList.add('hidden') 或 .remove('hidden')，不碰内联样式
• 如果必须用 display，先缓存原始值：if (!el.dataset.originalDisplay) el.dataset.originalDisplay = getComputedStyle(el).display
• 表格行数多时，优先隐藏整个 tbody，再用 documentFragment 插入匹配行，比逐行控制更快
