直接在dom上对12k行表格实时filter+innerhtml替换必然卡死，需用documentfragment+显隐控制、统一class选择器、search事件防抖、空值校验及提前break的for循环优化。
直接在 DOM 上对 12K 行表格做实时 filter + innerHTML 替换，必然卡死。这不是代码写得不够“优雅”的问题，而是浏览器渲染机制的硬限制——你得把计算和重绘从主线程里搬出去，或者干脆别让它发生。
用 documentFragment + 显隐控制代替删增节点
每次过滤都 tr[i].remove() 或拼接 innerHTML，会触发多次强制重排（reflow），12K 行下开销爆炸。显隐控制不改变 DOM 结构，只改 style.display，快一个数量级。
- 给所有数据行加统一 class，比如
data-row，避免用getElementsByTagName("tr")这种慢选择器 - 过滤时只遍历带该 class 的元素：
document.querySelectorAll(".data-row") - 匹配失败的行设为
display: none，成功的设为display: table-row（不是空字符串，否则可能继承错误 display 值） - 表头（
<thead>）和固定提示行（如“无结果”）必须加 <code>:not(.data-row)排除，否则会被误隐藏关键词搜索必须加防抖，且优先用 search 事件
oninput在用户每敲一个键就触发，12K 行下一次querySelectorAll+ 遍历就是 50ms 起跳，连打三下就卡住。而search事件只在用户明确提交（点放大镜图标、按回车）时触发，体验更稳。- 把
input改成type="search"，iOS/Android 键盘会自动显示清空按钮 - 监听
search而非input：el.addEventListener("search", handler) - 如果必须响应输入过程（比如带加载态），再加防抖：用
setTimeout+clearTimeout，延迟设 300ms —— 比 100ms 更可靠，能覆盖多数双字词输入间隙 - 空值判断必须用
value.trim().length === 0，否则用户输空格再删，会误触发全隐藏
多列模糊匹配别嵌套循环，提前 break
对每行遍历所有
td再逐个includes()，是常见性能黑洞。12K 行 × 平均 5 列 × 字符串扫描 = 百万级操作。关键不是“怎么写”，是“什么时候停”。- 不要写
Array.from(trs).forEach(row => [...row.cells].some(cell => cell.textContent.includes(keyword)))——some()内部仍会扫完所有单元格才返回 - 改用传统
for循环，匹配成功立刻break外层：for (let i = 0; i - 忽略大小写搜索，提前缓存正则：
const re = new RegExp(keyword, "i")，但务必先检查keyword是否为空或含^$.*+?[]等特殊字符，否则报错 - 若列数固定（如只有姓名、邮箱、状态三列），直接写死
cells[0].textContent、cells[1].textContent，比cells.length动态遍历快 15%～20%
真到 12K 行，前端筛只是权宜之计
哪怕全优化完，12K 行在低端安卓机上首次渲染仍要 200ms+，滚动时
display切换也会掉帧。这不是 JS 能解决的，是 DOM 承载量的物理边界。- 服务端分页 + 搜索：用户输关键词，发请求到后端，只返回匹配的 50 条，前端只渲染这 50 条 —— 最彻底的解法
- 前端虚拟滚动：只渲染可视区域 ±2 行，滚动时动态替换
textContent和dataset，用position: absolute控制位置，transform: translateY()做平滑滚动 - 如果必须全量加载，至少把原始数据存在
Array里，过滤逻辑跑在数组上，生成匹配 ID 列表，再批量查 DOM 更新显隐 —— 避免反复访问textContent这种高开销属性
最易被忽略的一点：table 布局本身就很重。如果业务允许，把
<table> 换成 <code><div role="table"> + Flex/Grid，配合 <code>contain: layout style paint，能减少 30% 渲染耗时。但前提是你的样式没强依赖table-cell的行为。 - 把
