直接遍历tr多条件筛选卡顿的主因是频繁DOM读写触发强制同步回流；应改用内存数组预处理+配置化条件过滤，并设行数阈值兜底分页或虚拟滚动。
为什么直接遍历 tr 做多条件筛选会卡死
用户一输就卡顿，不是 JS 慢，是浏览器在反复读取 DOM 属性（textContent、innerText）+ 频繁设置 style.display 时触发了强制同步回流。500 行 × 5 列表格，一次全量筛选可能触发 2500+ 次 DOM 访问，主线程直接被压垮。
- 每次
row.style.display = 'none'都会触发样式计算和布局重排 -
td.textContent.includes(keyword)在长文本或含 HTML 的单元格里极慢（需解析 DOM 树） - 多个条件叠加（如“状态=启用”且“日期>2026-01-01”且“金额>1000”）时，嵌套循环 + 条件判断让时间复杂度飙升
- 没有节流，输入框每敲一个字都执行一遍，连按“abc”可能触发 3 次完整扫描
filter() 用数组代替 DOM 遍历，但别忘了预处理
把原始数据存成纯 JavaScript 数组（比如 rowsData = [{id:1,name:'张三',amount:1200,...},...]），所有筛选逻辑都在内存里跑，完全避开 DOM。这是提速最有效的一环。
- 初始化时一次性映射：用
Array.from(table.querySelectorAll('tbody tr')).map(row => ({...}))提取字段，不要留row引用 - 对数字/日期字段，提前转成
Number或Date类型，避免每次筛选都parseInt()或new Date() - 字符串字段统一用
.toLowerCase()存储副本（如nameLower），搜索时直接比小写，省去每次调用 - 慎用
JSON.parse(JSON.stringify())深拷贝——大数据量下 GC 压力大；用structuredClone()（现代浏览器）或手动浅拷贝 + 关键字段覆盖
多条件组合筛选，用对象配置比硬编码 if 更稳
用户勾选“部门=技术部”“状态≠禁用”“创建时间∈[2025-01-01,2026-10-01]”，硬写三层 && 易漏边界、难维护。用配置驱动更可靠。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 每个条件存为对象：
{field: 'dept', op: 'eq', value: '技术部'}，{field: 'status', op: 'ne', value: '禁用'} - 预定义操作符函数：
filters.eq = (a, b) => a === b，filters.range = (val, [start, end]) => val >= start && val - 筛选时用
rowsData.filter(row => conditions.every(c => filters[c.op](row[c.field], c.value))) - 空条件自动跳过（
value为空时不参与过滤），避免误筛
真实场景下的性能临界点与兜底策略
即使做了以上优化，10 万行原始数据仍不适合前端全量加载筛选。必须设防线。
立即学习“前端免费学习笔记（深入）”；
- 行数 > 5000 时，禁用全量客户端筛选，强制走分页 + 后端搜索（传
filter参数给 API） - 行数 2000–5000 时，启用虚拟滚动（如
virtuoso），只渲染视口内 50 行，筛选结果仅更新数据索引，不重建 DOM - 输入延迟用
setTimeout节流（非防抖）：用户还在打字就取消上一次定时器，但最后一下必须执行，避免“输完没反应” - 筛选后若匹配行数为 0，显示“未找到”，但保留原始数据引用——别清空数组，下次改条件能秒出结果
new Date('2026-10-27') 默认转成 UTC 零点，比本地时间早 8 小时，导致“今天”的数据总被筛掉。统一用 date.toISOString().slice(0,10) 对齐，比拼字符串更安全。 
