动态插入 时必须转义 HTML 特殊字符

事情在动态场景下会变得棘手。当高亮的内容来自用户输入——比如搜索框里的关键词、URL 里的查询参数——如果直接把它拼接进 HTML 字符串，无异于打开了潘多拉魔盒。

想象一下，用户搜索了 。如果不经处理就直接套上 标签，这段代码就会被浏览器当作可执行的脚本，跨站脚本攻击（XSS）就这么发生了。

立即学习“前端免费学习笔记（深入）”；

所以，安全防线必须筑牢。正确的做法是，先对原始文本进行 HTML 实体转义，然后再包裹高亮标签。

• 在 Ja vaScript 中，一个稳妥的方法是使用 textContent 属性来创建文本节点，它能自动处理转义，之后再替换到 DOM 中。
• 要尽量避免使用 innerHTML += '' + keyword + '' 这种危险的字符串拼接。
• 如果必须使用正则表达式进行全局替换（例如 str.replace(/keyword/g, '$&')），务必先对 keyword 本身进行转义，转义函数类似 keyword.replace(/[&"'`=/]/g, c => `${c.charCodeAt(0)};`)。

的样式可以完全自定义，但别忽略可访问性

默认的亮黄色虽然醒目，但并非放之四海而皆准。在深色模式的主题下，或者在色弱、色盲用户眼中，这种对比度可能完全不够，甚至难以辨认。

因此，自定义样式几乎是必然的选择。但在动手时，有几点原则需要记住：

• 对比度是底线：文字颜色与背景色的亮度对比度至少要达到 4.5:1，确保任何人都能看清。
• 增强识别度：除了调整颜色，可以增加一点内边距（padding），或者辅以细微的边框、阴影，让高亮区域更明确。

  mark {
    background: #ffeb3b;
    color: #212121;
    padding: 0 2px;
  }

• 顾及辅助技术：屏幕阅读器通常不会对 有特殊播报。如果确有必要进行语音提示，可以谨慎添加 aria-label 属性，但要避免造成冗余信息干扰。
• 别让语义消失：切忌写成 mark { background: transparent; text-decoration: underline; } 这种纯装饰样式。如果只是为了下划线而没有任何背景色变化，那就完全丧失了 的语义，这时直接用 标签配合样式才是正确的选择。

服务端渲染或静态页面中批量高亮要小心正则边界

在后端或构建时进行批量文本替换，是另一种常见的高亮场景。这里最大的坑，往往出在正则表达式的“单词边界”处理上。

一个经典的错误是：想要高亮 “cat”，却误伤了 “education”。

错误写法：text.replace(/cat/g, 'cat')
结果：“education” 变成了 “educacation”，令人哭笑不得。

正确的做法需要分步走：

• 锚定边界：对于英文单词，使用 \b 来确保匹配的是完整的单词。例如：/\bcat\b/gi（i 标志用于忽略大小写）。
• 转义元字符：如果关键词本身包含正则表达式的特殊元字符（比如 +、.、?），必须先进行转义：keyword.replace(/[.*+?^${}()|[\]\]/g, '\\$&')。
• 中文处理：中文没有明确的单词边界，所以不需要 \b。但要注意全角/半角字符、空格和标点符号可能造成的干扰。通常可以采用更精确的匹配模式，例如利用正向/负向预查来界定词的边界。

说到底，实现高亮功能本身并不复杂。真正的挑战在于，如何在海量、多变且可能不可信的输入来源下，在编码环境、视觉呈现和辅助功能之间，始终保持安全、精确和可用。转义和边界处理，这两道关卡只要有一道失守，轻则导致页面显示混乱，重则可能引发安全漏洞。这其中的分寸，正是前端工程师专业性的体现。