重叠文本高亮不能用 innerHTML.replace()，因其会生成非法嵌套标签、破坏DOM结构、丢失事件和样式；应使用 TreeWalker 遍历文本节点，配合 Range.surroundContents() 精确包裹并 normalize() 合并节点，同时用 data-highlight-id 精准管理生命周期。
直接用 innerHTML.replace() 处理重叠文本高亮，几乎必然导致 DOM 错乱、样式错位、事件丢失——因为重叠匹配会反复切割同一段文本节点，生成非法嵌套或断裂的标签结构。
为什么重叠文本不能用简单正则替换
比如搜索词 "ab" 和 "bc" 在字符串 "abc" 中是重叠的。用 str.replace(/ab|bc/g, '<mark>$&</mark>') 会产出 <mark>ab</mark>c 或 a<mark>bc</mark>，但无法同时高亮两个重叠片段；若强行双写，就会变成 <mark><mark>ab</mark>c</mark> 这类非法嵌套，浏览器会自动修复并丢弃内层 mark，最终只剩一层高亮。
更严重的是：所有基于字符串拼接的方案，都会跳过真实 DOM 结构（如 <strong>ab</strong>c），把标签当普通字符处理，造成 XSS、脚本执行、属性丢失等后果。
用 Range + document.createElement('mark') 精确包裹重叠选区
现代浏览器支持通过 window.getSelection() 或手动构造 Range 对象，在任意位置插入 mark 而不破坏原有结构。这是唯一能安全处理重叠、跨节点、带格式文本的方案。
立即学习“前端免费学习笔记（深入）”；
- 先用
document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT)遍历所有文本节点，跳过空节点和脚本/注释 - 对每个文本节点，用
node.textContent做纯字符串匹配，记录所有重叠起始/结束索引（注意：需按起始位置升序、长度降序排序，避免短标签在长标签内部被提前截断） - 从后往前遍历匹配区间（倒序），每次调用
range.setStart(node, start)和range.setEnd(node, end)，再用range.surroundContents(markEl) - 每次
surroundContents后立即调用node.parentNode.normalize()，合并因拆分产生的相邻文本节点
防重复高亮与清除逻辑必须绑定到原始节点
重叠高亮后，同一个文本节点可能被多个 mark 包裹，后续清除不能靠 document.querySelectorAll('mark').forEach(el => el.remove())——这会删掉用户手动加的 mark，也清不干净嵌套残留。
推荐做法是给每次生成的 mark 加唯一标识：
- 创建时：
const mark = document.createElement('mark'); mark.dataset.highlightId = 'search-20261027-1'; - 清除时：
document.querySelectorAll('mark[data-highlight-id^="search-"]')，精准过滤 - 避免用 class 名做清除依据，CSS 类易冲突，且无法区分不同搜索会话
移动端重叠高亮要绕过 selection API 的兼容陷阱
iOS Safari 在输入法弹出时经常清空 window.getSelection()，导致基于选区的高亮失效；Android Chrome 则可能将长按选区识别为单词而非字符序列，跳过标点导致边界偏移。
稳妥方案是放弃依赖用户手势，改用「关键词定位 + 节点坐标映射」：
- 预先把全文本节点按顺序扁平化为数组：
const textNodes = [...walker].filter(n => n.textContent.trim()) - 搜索时遍历该数组，用
textContent.indexOf(keyword, fromIndex)手动找所有重叠位置，并记录所属节点索引 - 渲染时只操作这些已知安全的文本节点，完全避开
getSelection()的不稳定链路
真正麻烦的不是怎么高亮，而是怎么让高亮在滚动、缩放、输入法切换、动态内容加载后依然稳定存在——所有依赖字符串替换或全局 CSS 的方案，到这里都会开始漏匹配、多包裹、错定位。必须把高亮动作锚定在 DOM 节点+偏移量这一层，而不是“看起来像文本”的字符串。
