不能只靠 innerHTML 替换，因其会重置所有 DOM 状态（如展开行、聚焦输入框、选中复选框），导致用户操作丢失；正确做法是维护纯净 JS 数据源，仅控制 tr 显示状态，并配合防抖与标准化搜索逻辑。
表格数据过滤为什么不能只靠 innerHTML 替换？
直接拼接字符串写入 innerHTML 看似简单，但会重置所有 DOM 状态：已展开的详情行、聚焦的输入框、选中的复选框全丢失，用户操作瞬间清零。真实场景中，表格往往带排序箭头、分页控件或行内编辑态，一刷就崩。
正确做法是只操作 tr 的显示状态，保留原始 DOM 结构：
- 给每行
tr添加唯一data-id或业务标识，避免依赖索引 - 用
tr.style.display = 'none'隐藏不匹配项，'table-row'恢复显示 - 过滤后检查是否全隐藏——若无结果，需显式显示“暂无数据”行（该行本身不能被过滤逻辑影响）
filter() 之前必须先提取原始数据源
从表格 HTML 解析数据再过滤，效率低且易出错（比如单元格含按钮、链接或空格）。更稳的方式是维护一份纯净的 JS 数据数组，表格渲染和过滤都基于它：
- 初始化时把后端返回的 JSON 或静态数据存为
rawData数组，每个对象字段对应列（如{name: '张三', dept: '前端'}） - 渲染函数遍历
rawData生成tr，并给每行绑定data-index属性指向原数组下标 - 过滤时只对
rawData调用filter()，再用返回的新数组下标去批量控制对应tr显示/隐藏
这样既避免重复解析 HTML，也方便后续加搜索高亮、模糊匹配等扩展。
立即学习“Java免费学习笔记（深入）”；
输入框防抖不是可选项，而是必做项
用户每敲一个字就触发一次过滤，尤其数据量过百时，会明显卡顿甚至浏览器假死。典型错误是直接监听 input 事件并立即执行过滤逻辑。
实操建议：
- 用
setTimeout+ 清除前序定时器实现简易防抖，延迟设为200ms 左右（太短没效果，太长感知延迟） - 记录上一次过滤关键词，若新输入值未变（比如空格增减），跳过执行
- 首次输入或清空时，可提前设置
placeholder提示“按姓名/部门搜索”，降低误操作率
别用 Lodash 的 debounce——就几行代码的事，引入库反而增加首屏负担。
多字段联合搜索容易漏掉大小写和空白符
用户搜“前端”能匹配到，但搜“ 前端 ”或“FE”就失效，这是常见疏忽。单纯用 includes() 不够：
- 搜索前统一转小写：
keyword.toLowerCase()，字段值也同步处理 - 用
trim()去除首尾空格，避免用户输空格导致匹配失败 - 若需支持模糊匹配（如搜“zhang”匹配“张三”），得额外引入拼音库或预生成拼音字段，不要在运行时临时转换
- 字段为空时，
undefined或null会报错，务必用String(field || '')安全转换
真正难的不是写过滤逻辑，而是让不同字段的搜索行为一致——比如部门用精确匹配，姓名用包含匹配，这种差异必须在配置里写死，而不是散落在条件判断中。
