HTML搜索高亮卡顿主因是关键词未转义、多词反复遍历DOM、滥用innerHTML及未防抖；应转义元字符、合并正则、textContent提取+局部更新、createTreeWalker遍历文本节点并normalize，且高亮逻辑需150ms防抖。
HTML 搜索高亮本身不会“拖慢关键词”，但关键词处理不当会显著拖慢高亮过程 —— 尤其在 DOM 复杂、文本量大或正则滥用时。
为什么高亮会变卡：关键词没做清洗就进正则
直接把用户输入塞进 new RegExp(keyword, 'gi') 是最常见卡顿源头。比如搜 "[a-z]+.js"，浏览器会尝试回溯匹配整个 DOM 文本，遇到嵌套标签或长段落极易触发引擎性能惩罚。
- 用户输入含正则元字符（
.、^、[、(等）必须先转义，用keyword.replace(/[\^$.*+?()[]{}|]/g, '\$&') - 多词搜索别用
split(' ').map(w => new RegExp(w, 'gi'))反复遍历 DOM；应合并为单次正则：new RegExp('(' + words.map(escape).join('|') + ')', 'gi') - 避免对
document.body全局操作；限定容器如document.querySelector('.searchable-content')
textContent 提取 vs innerHTML 替换：性能差在哪
用 innerHTML.replace() 看似快，实则每次调用都会触发 HTML 解析、DOM 重建、样式重排 —— 高亮 10 次 = 重排 10 次。而 textContent 提取纯文本后只操作字符串，再用 document.createElement('mark') 和 replaceChild() 局部更新，开销低一个数量级。
- 提取文本前先
el.querySelectorAll('mark').forEach(m => m.replaceWith(m.textContent))清旧标记，避免节点爆炸 - 对目标容器调用
createTreeWalker(el, NodeFilter.SHOW_TEXT)遍历文本节点，比递归childNodes更稳定 - 匹配后立即调用
el.normalize()合并相邻文本节点，防止后续操作误判
200 条以上数据必须加防抖，但不是加在输入框上
防抖要加在高亮执行环节，而不是 input 事件监听里。否则用户快速输入 “react” 时，会连续触发 5 次高亮逻辑，但只有最后一次结果有效，前 4 次全是白忙。
立即学习“前端免费学习笔记（深入）”；
- 用
let timeoutId; clearTimeout(timeoutId); timeoutId = setTimeout(() => highlight(el, keyword), 150) - 防抖阈值设 150ms 足够覆盖打字间隙，又不明显延迟反馈
- 若关键词为空或长度
真正容易被忽略的是：高亮后 DOM 节点数翻倍，如果后续代码还依赖 querySelectorAll('p') 或 children.length 做判断，很可能出错。动手前先想清楚 —— 你是要改结构，还是只改视觉。
