innerHTML.replace()高亮易崩，因未转义特殊字符、未剥离HTML标签、误替换属性值，导致DOM结构损坏、XSS风险或JS报错。
直接用 innerHTML 替换关键词高亮，90% 的场景会出安全或渲染问题——不是不能用，而是必须加转义、限范围、清旧标。
为什么 innerHTML.replace() 高亮一用就崩
浏览器不校验你塞进去的字符串，searchTerm 里带 、<code>"、 或正则元字符（比如 .*?），new RegExp(searchTerm, 'gi') 就会报错或匹配失控；更糟的是，如果用户输 <img src="https://img.php.cn/" alt="html如何实现页面内关键词高亮定位_html前端搜索">，直接执行脚本。
- 所有输入必须先用
searchTerm.replace(/[-/\^$*+?.()|[]{}]/g, '\$&')转义正则特殊字符 - 永远别对
document.body.innerHTML操作，只处理明确容器，例如document.querySelector('.searchable-content') - 高亮前先清除已有
mark或span.highlight：用el.querySelectorAll('mark, span.highlight').forEach(n => n.replaceWith(n.textContent))
用 mark 标签比 span 更靠谱的三个实际原因
mark 是语义化标签，辅助技术（如读屏器）能识别这是“上下文相关强调”，而 span 只是普通容器。但它不是开箱即用——默认样式在禁用 UA 样式的环境（比如某些邮件客户端、iOS 阅读模式）下会完全消失。
- 必须显式声明
background-color和color，哪怕和默认值一样 - 加
padding: 0.2em 0.4em和border-radius: 2px，否则边缘紧贴文字难辨识 - 避免用
display: inline-block或vertical-align改变mark行内行为，它被插入到段落中时可能撑开行高或破坏换行
多词搜索命中逻辑怎么写才不漏不滥
includes() 看似简单，但搜 ui 会错误匹配 building 里的子串，搜 Node 又会漏掉 node.js（大小写不一致）。真正可用的过滤得拆开比、逐个判、统一规一。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 先转小写：
item.title.toLowerCase().includes(keyword.toLowerCase()) - 多词用空格或逗号拆：
keywords = input.trim().split(/[s,]+/).filter(Boolean) - 每个词都得命中才算通过：
keywords.every(k => item.title.toLowerCase().includes(k.toLowerCase())) - 数据量超 200 条时，把搜索逻辑包进
setTimeout+clearTimeout防抖，否则每敲一个字都重绘 DOM
高亮后 DOM 节点数量突增，后续操作容易重复或失效
用 replaceChild() 插入 mark 后，原来的一个文本节点变成多个节点（文字 + mark + 文字），如果你之前靠 querySelectorAll('.item') 缓存了节点列表，循环时可能反复处理已被替换过的片段，甚至报 NotFoundError。
- 每次高亮完立刻调用
el.normalize()，合并相邻文本节点，减少碎片 - 不要缓存需高亮的节点列表，每次搜索都重新
querySelectorAll() - 若必须复用节点引用，高亮前先记录原始文本内容，高亮后用
textContent对比确认是否已处理过
最易被忽略的一点：高亮不是终点，而是搜索流程中承上启下的环节——它依赖过滤结果，又影响后续点击定位或滚动锚点。别只盯着颜色对不对，要盯住节点是否真实可访问、样式是否在各种 UA 下稳定、性能是否扛得住连续输入。
