输入实时搜索时应监听input事件，遍历tbody下tr的cells文本，trim后toLowerCase匹配；空搜全显，加防抖与文本缓存优化性能；模糊用includes，精确匹配需正则或数值转换。
搜索框输入后如何实时隐藏不匹配的 <tr> 行
直接操作 DOM，遍历 <tbody> 下所有 <tr>，用 textContent 匹配关键词即可。别用 innerHTML，容易误匹配 HTML 标签文本或实体编码（比如 ）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听搜索框
input事件，而非change—— 后者要失焦才触发，体验卡顿 - 对搜索词做
.trim().toLowerCase()，再对每行tr.textContent.toLowerCase()查找，避免大小写和空格干扰 - 匹配不到时设
tr.style.display = 'none'；匹配到则还原为''（不要用'table-row'，兼容性风险） - 记得先显示所有
<tr>，再筛选 —— 否则连续输入会把已隐藏的行“漏掉”
多列搜索怎么写？querySelectorAll 和 cells 怎么配合
不能只查整行文本，否则某列含“张三”但搜索“北京”就搜不到。得逐列比对，任一列命中即保留该行。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
tr.cells获取该行所有单元格（<td>或<th>），它是只读集合，比querySelectorAll('td, th')更快更可靠 - 遍历时用
cell.textContent.trim()去除换行/空格干扰，再做includes()判断 - 只要有一个
cell匹配，就跳出循环并显示该tr；全都不匹配才隐藏 - 注意：表头行
<thead><tr>不参与筛选，过滤前先排除它（加:not(.header)类或用tbody.querySelectorAll('tr')）
搜索性能差、卡顿怎么办？特别是几百行表格
每输一个字都遍历全部 <tr> + cells，DOM 读取频繁，尤其在低端设备上明显卡顿。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 加防抖：用
setTimeout+clearTimeout，延迟 200ms 再执行筛选，避免高频触发 - 提前缓存文本：初始化时遍历一次，把每行各列的纯文本存进数组或
Map，后续只查内存数据，不碰 DOM - 避免重复查询：搜索词为空时，直接
tr.style.display = ''全部显示，不走匹配逻辑 - 真到上千行，考虑虚拟滚动 —— 但纯前端筛选场景下，先优化缓存+防抖，90% 情况够用
为什么搜索“123”却把“1234”也显示出来了？
这是 includes() 的正常行为，不是 bug。但用户常期望精确匹配数字或 ID，比如搜“123”只想要 ID 列值等于 123 的行。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 区分模糊匹配和精确匹配：给搜索框加个 checkbox，勾选后用
===或正则^123$，否则保持includes() - 数值列单独处理：若某列全是数字，可尝试
Number(cell.textContent.trim()) === Number(keyword)，但要注意NaN安全 - 正则更可控：
new RegExp('^' + keyword.replace(/[-[]{}()*+?.,\^$|#s]/g, '\$&') + '$').test(cellText)，用于精确匹配且转义特殊字符 - 记住：默认行为是子串匹配，用户没提“精确”，就别擅自改成严格相等
表格搜索看着简单，真正上线常卡在空格、换行、大小写、防抖时机和精确/模糊边界上 —— 这些细节不提前想清楚，后期改起来比重写还累。
