直接innerHTML拼接表格行会卡顿，因需销毁重建DOM、丢失事件与焦点且易XSS；应改用template+DocumentFragment克隆渲染，并将筛选逻辑从DOM遍历转为数据驱动filter计算。
为什么直接 innerHTML 拼接表格行会卡顿
每次搜索或筛选都用 tbody.innerHTML = htmlString 重绘，浏览器要销毁所有 tr、重建 DOM 树、重新绑定事件、丢失焦点——千行以上就明显掉帧。更糟的是，未转义动态内容还会触发 XSS。
- DOM 重建开销随行数线性增长，2000 行时单次重绘可能超 16ms（一帧时限）
-
innerHTML不保留原有事件监听器，比如行内编辑的input失去 focus 状态 - 模板字符串里拼
value="${data.name}"若name含<script>就执行脚本
正确做法是用 <template> 预解析结构，克隆 template.content.cloneNode(true) 插入，实测比字符串快 2–3 倍（Chrome 128+）。
如何用 template + DocumentFragment 批量渲染
核心不是“怎么填”，而是“在哪填”和“怎么防错”。<template> 内容不参与初始渲染，克隆后插入轻量且安全。
- 模板必须写明
<tbody><tr><td></td></tr></tbody>，不能只写<tr> - 克隆后立即遍历节点填值：
row.querySelector('.name').textContent = item.name，别用innerHTML - 有交互的节点（如编辑按钮）要在克隆后立刻绑定事件，Shadow DOM 中不能依赖事件委托
- ID 冲突必须处理：
clone.querySelectorAll('[id]').forEach(el => el.id += '-'+Math.random().toString(36).substr(2, 9))
避免在模板里写 <style>；样式应进 shadowRoot 或用 CSSStyleSheet 注入。
立即学习“前端免费学习笔记（深入）”；
筛选逻辑该跑在 DOM 上还是数据上
2000 行以内可直接 DOM 遍历：table.querySelectorAll('tbody tr') + row.cells 逐单元格比对；超量就必须切到数据驱动模式。
- DOM 遍历前提：显式写
<tbody>，跳过row.cells.length === 0的表头行 - 缓存原始数据数组，筛选时用
originalData.filter(...)计算，再批量渲染结果 - 多条件组合筛选时，把 checkbox 值转成
Set：const brands = new Set(formData.getAll('brand'))，查brands.has(item.brand)比array.includes()快 - 防抖必须加：
input事件里用clearTimeout+setTimeout，500ms 内只执行最后一次
空搜索词时，别留着上次的 display: none，统一设 row.style.display = ''。
多表格共存时如何避免互相干扰
全局 document.getElementById('myTable') 一搜全中，根本没法用。关键在建立搜索框与目标表格的显式绑定关系。
- HTML 中给搜索框加
data-target="#user-table"或data-target=".order-table" - JS 里用
document.querySelectorAll('[data-target]')批量绑定，每个input只控制对应target选中的表格 - 筛选状态不要存在全局变量里，每个表格实例维护自己的
currentFilter对象 - 移动端注意 touch 区域：复选框的
label必须包裹input，否则点不中
真正容易被忽略的不是语法细节，而是临界点——当表格动态渲染出 3000+ 行，每次 input 都触发全量 DOM 遍历，UI 就会卡顿；这时候该抽数据、用 filter() 纯逻辑计算，再重绘 tbody，但那是另一层优化了。
