直接replace innerHTML会触发灾难性重排，因其强制销毁并重建整个子树，导致事件监听器丢失、表单值清空、组件卸载、滚动重置及完整重排重绘。
为什么直接 replace innerHTML 会触发灾难性重排
大规模文本高亮时，element.innerHTML = element.innerHTML.replace(...) 不是慢，是直接让浏览器重建整个子树——DOM 节点全被销毁再重解析，所有事件监听器丢失、input 值清空、textarea 内容归零、动态插入的组件卸载。这不是性能问题，是结构坍塌。
根本原因在于：innerHTML 赋值强制触发 HTML 解析器从头开始构建 DOM 子树，绕过所有现有节点引用。哪怕只高亮一个词，也会让父容器内全部 div、p、span 重新实例化。
- 表单控件（如
<input value="已填写">）变成纯文本，值不可恢复 - 第三方组件（React/Vue 挂载点）被剥离，JS 状态丢失
- 滚动位置重置，用户正在阅读的位置跳回顶部
- 触发完整重排（reflow）+ 重绘（repaint），CPU 占用飙升
TreeWalker 遍历文本节点的实际开销控制
用 document.createTreeWalker(root, NodeFilter.SHOW_TEXT) 只遍历文本节点，避免了元素节点干扰，但大规模文档（如 >50KB 文本）下仍可能卡顿——关键不在遍历本身，而在每次 replaceChild() 触发局部重排。
真正可优化的点是「批量合并操作」：不要每匹配一次就替换一个节点，而是先收集所有待高亮的 TextNode 和其匹配位置，再用 DocumentFragment 批量插入 mark 元素。
立即学习“前端免费学习笔记（深入）”；
- 遍历时只调用
node.textContent，不修改 DOM，无渲染开销 - 对每个节点执行正则匹配前，先检查
node.textContent.length ，跳过明显不可能匹配的长文本节点 - 使用
String.prototype.indexOf()快速预筛，比RegExp.test()开销低 3–5 倍 - 匹配结果存为
{ node, start, end }数组，后续统一处理
mark 元素插入后的 normalize() 不可省略
高亮后若不调用 node.parentNode.normalize()，会出现相邻文本节点分裂：比如原文 “hello world” 被拆成 “hello world”，实际生成三个节点 —— “hello ” + mark + “”，中间空文本节点残留。下次再高亮 “hello”，就可能匹配到 “hello ” 后面的空格，或因节点边界错位导致 Range.surroundContents() 报 InvalidNodeTypeError。
normalize() 合并相邻文本节点，同时清除空节点，是维持 DOM 结构稳定的必要步骤，但它本身也触发一次微小重排。所以必须在所有 replaceChild() 完成后再统一调用一次，而不是每次替换后都调用。
- 只对被修改过的父节点调用
normalize()，避免遍历整棵树 - 记录所有被替换过的
node.parentNode，去重后批量执行normalize() - 注意：IE 不支持
normalize()，但 IE 已淘汰；若需兼容旧 Safari，可用手动合并逻辑兜底
中文词边界匹配与性能权衡
搜“服务”时高亮“服务器”是典型中文误匹配，用 (? 可缓解，但正则引擎要扫描前后字符，比 <code>/服务/g 慢 2–3 倍。对万字级文档，这种开销会累积。
更实用的做法是分层处理：首屏可见区域用带边界的正则，滚动加载区域用简单全局匹配，再加人工干预开关（如 checkbox 标注“精确匹配”）。
- 默认关闭词边界，避免首次渲染延迟
- 用户勾选“精确匹配”后，才启用 Unicode 边界断言
- 对
pre、code等纯文本容器，始终用简单匹配，因为内部无语义分词需求 - 避免在
input或textarea的父容器上调用高亮逻辑——它们的内容不应被 DOM 操作污染
真正难的不是写对一行 mark，是确保它插进去之后，页面还能正常滚动、输入、聚焦、读屏——这些细节不显眼，但漏掉任何一个，高亮功能就从辅助变成障碍。
