直接遍历DOM漏匹配因只查固定列而非整行任意列；应遍历row.cells并防空值；用input事件而非keyup/change；大数据量需缓存字符串数组+防抖；结果为空时动态插入提示行；须同步更新数据源与视图。
为什么直接遍历 DOM 会漏匹配
很多人写 tr.cells[0].textContent 只查第一列，输入 “产品经理” 却搜不到职业在第三列的行——本质是把多列表格当成了单列结构处理。真正要匹配的是“整行中任意一列”，不是“某固定列”。
必须用 row.cells 获取所有单元格，再逐个判断：
• 跳过 row.cells.length === 0 的表头行，否则报错
• 每个单元格先 .textContent?.trim() || '' 防空值崩溃
• 不要用 innerText，Safari 旧版不稳，textContent 更可靠
input 事件比 keyup 和 change 都关键
onkeyup 漏掉粘贴、自动填充、语音输入；onchange 只在失焦时触发，用户连输 “react” 六次，只响应最后一次——搜索体验直接断裂。
正确做法是：
• 用 addEventListener('input', handler) 绑定
• 输入框值为空时，必须显式恢复所有 tr.style.display = ''，不能留着上一次的隐藏状态
• IE11 不支持 input？可 fallback 到 propertychange，但现代项目基本不用管
数据量超 500 行时性能怎么扛
每次输入都遍历 DOM，3000 行表格会明显卡顿，因为 row.cells[i].textContent 是高开销 DOM 访问。
优化核心是“减少 DOM 查询次数”：
• 提前缓存：用 Array.from(rows, r => Array.from(r.cells).map(c => c.textContent?.trim() || '')) 把整张表转成二维字符串数组
• 后续过滤只操作这个数组，不再碰 DOM
• 配合防抖（200ms），避免用户连敲时反复重算
• 真到万级数据？该考虑分页或后端筛选，前端硬扛没意义
搜索结果为空时 UI 怎么不让人懵
清空 tbody 或全设 display: none 后只剩表头，用户第一反应是“页面卡了”或“我输错了”。
更稳妥的做法：
• 动态计算列数：const colCount = table.querySelector('thead tr')?.cells.length || table.querySelector('tbody tr:first-child')?.cells.length || 1
• 插入提示行：<tr><td colspan="${colCount}">未找到“${keyword}”</td></tr>
• 关键词要带进文案，让用户确认搜的是自己想要的
• 如果原始数据就是空的，提示应是“暂无数据”，而非“搜索无结果”——二者语义完全不同
立即学习“前端免费学习笔记（深入）”；
最常被忽略的不是怎么写逻辑，而是数据源和视图不同步：过滤后只改了 DOM，但页码显示、总条数、导出按钮的数据源仍指向原始数组，用户点导出就会拿到全部数据，而不是当前筛选结果。
