表格搜索框无反应的主因是元素未获取到或JS执行过早；应确保DOM加载完成、正确绑定input事件、用textContent匹配并缓存节点，配合防抖提升性能。
表格搜索框绑定 input 事件时为什么没反应？
常见原因是没给 input 元素加 id 或 class，导致 document.getElementById() 返回 null；或者事件监听写在 DOM 渲染前，脚本放在 <head> 里又没加 defer。务必确认：搜索框存在、JS 在表格 DOM 加载后执行、事件回调函数名拼写正确。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把
<script>标签移到</body>前，或用DOMContentLoaded包裹初始化逻辑 - 用
console.log(document.getElementById('search-input'))检查是否获取到元素 - 监听
input事件（不是change），实时响应用户输入
如何遍历表格行并隐藏不匹配的 <tr>？
不能只遍历 <tbody> 下的 <tr>，要跳过表头（<thead>）和页脚（<tfoot>），否则可能误隐藏标题行。另外，直接设 tr.style.display = 'none' 会破坏原有样式继承（比如 hover 效果），推荐用 CSS class 控制显隐更稳妥。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
table.querySelectorAll('tbody tr')精确获取数据行 - 为表格行预设一个 class，如
data-row，搜索时统一增删hidden类 - 匹配逻辑建议转成小写：
cellText.toLowerCase().includes(searchTerm.toLowerCase())，避免大小写敏感问题 - 每行至少有一个单元格匹配就显示，全都不匹配才隐藏
textContent 和 innerText 在搜索中选哪个？
选 textContent。它返回所有文本内容（含隐藏元素里的文字），且性能更好、兼容性更广；innerText 会忽略 display: none 的内容，还受 CSS 排版影响，在某些旧版 Safari 中行为不一致。搜索场景下，你希望匹配的是“用户看到的全部可读文本”，但前提是这些文本真实存在于 DOM 结构中——textContent 更符合这个预期。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 遍历每行的每个
<td>和<th>，取其textContent - 避免用
innerHTML，它会把 HTML 标签当字符串匹配，容易误匹配或 XSS 风险 - 空单元格的
textContent是空字符串，不会报错，但需注意''.includes('xxx') 恒为false
搜索性能差、输几个字就卡顿怎么办？
核心瓶颈在于每次输入都重跑整个表格遍历 + 字符串匹配。100 行以内基本无感，但超过 500 行就会明显延迟。不需要引入 Debounce 库，原生用 setTimeout + clearTimeout 就够用。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 设置 200ms 延迟：用户停止输入 200ms 后再执行过滤，避免高频触发
- 缓存
tbody引用和所有tr节点列表，别每次都在 DOM 里重新查 - 如果数据量真大（>5000 行），考虑分页或虚拟滚动，纯前端搜索已不现实
复杂点往往不在算法，而在边界：空搜索词要不要显示全部？大小写是否区分？是否支持正则？这些细节不定义清楚，后续维护成本远高于初始实现。
