搜索框应通过防抖（200ms）、缓存tr节点、精准匹配data-search列、toLowerCase统一大小写、状态管理替代display隐藏来避免卡顿和功能错乱。
搜索框怎么绑定到表格上才不会卡顿
直接监听 input 事件做全量遍历是常见写法，但表格行数一过百，输入时明显卡顿。关键不是“能不能搜”，而是“搜得顺不顺”。filter 和 includes 没问题，但每次输入都重跑整个 tbody 的 tr 遍历，CPU 负担大。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
debounce控制执行频率，延迟 200ms 再触发过滤（用户停顿打字后才查） - 只比对
td文本内容，跳过th、caption和空格/换行符（textContent.trim()） - 缓存原始
tr节点列表，避免重复调用querySelectorAll('tbody tr') - 隐藏行用
tr.style.display = 'none'，别用remove()—— 否则清空搜索框时还得重建 DOM
怎样让搜索支持多列或指定列
默认搜所有 td 很方便，但实际业务常要限定列，比如只搜“姓名”和“部门”，跳过“操作”列。硬编码列索引容易错，尤其表格结构后期调整。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给目标列的
td加data-search="true"属性，代码里用td[data-search]精准选取 - 如果列头有明确文字（如
th内容为“邮箱”），可用Array.from(thList).findIndex(th => th.textContent.includes('邮箱'))动态定位列号 - 不推荐用 class 名匹配列，因为 CSS 类名易变，且可能被样式库污染（比如
ant-table-cell） - 搜索值为空字符串时，务必恢复所有
tr显示，否则清空输入框后表格空白
大小写和中文模糊匹配怎么处理
用户输“张三”，表格里是“张三丰”，搜不到；输“JS”，表格里是“javascript”，也失败。原生 includes 是精确子串匹配，没做任何归一化。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 统一转小写比较：
cellText.toLowerCase().includes(keyword.toLowerCase()) - 中文场景可加简单去空格和全角转半角（用正则
.replace(/[\u3000-\u303f\u3040-\u309f\u30a0-\u30ff\uff00-\uff9f\u4e00-\u9faf\u3400-\u4dbf]/g, ...)），但别上分词库——太重 - 若需“张三”匹配“张三丰”，改用
cellText.indexOf(keyword) !== -1即可，不用正则，避免RegExp编译开销 - 注意：不要对 keyword 做
trim()后再搜，否则用户输空格开头会意外命中（比如搜“ 张三”应视为无效输入）
为什么搜索后排序失效或分页混乱
很多表格自带排序或分页逻辑，一旦你用 display: none 隐藏行，后续点击表头排序，那些被隐藏的行可能突然又冒出来，或者分页器算错总条数。这不是搜索逻辑的问题，而是状态没同步。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要单独操作 DOM 显示/隐藏，把“是否可见”状态存在 JS 变量里（例如
visibleRows = allRows.filter(...)），后续排序、分页都基于这个数组驱动渲染 - 如果必须用原生表格不重绘，至少在搜索后手动触发一次分页器的
refresh()或重设total属性（看分页组件 API） - 避免在
tr上直接写style，改用 class 切换（如tr.classList.toggle('hidden', !match)），方便 CSS 控制和调试 - 记住：搜索只是视图层过滤，不影响原始数据源；但如果你的分页依赖 DOM 节点数量，那就必然出错
真正麻烦的不是写几行过滤代码，而是搞清表格当前是否受其他脚本控制、有没有虚拟滚动、是否用了框架封装的 table 组件——这些都会让原生 JS 搜索变成“表面能用，实际掉坑”。动手前先 console.log(table.querySelector('tbody').children.length) 看看真实行数，比盲目套代码靠谱得多。
