mark 是唯一传达“上下文相关高亮”语义的元素，仅适用于搜索关键词、文档引用术语、代码示例修改部分三类场景；误用会导致语义丢失、可读性下降或 XSS 风险。
mark 标签不是“加个黄底”的快捷方式，它是唯一能向浏览器和辅助技术传达“这是当前上下文相关高亮”的语义化元素。用错场景或忽略安全与样式约束，高亮会失效、不可读，甚至引入 XSS 风险。
什么时候必须用 mark，而不是 span + class
只在以下三类明确场景中，mark 不可替代：
- 搜索结果页中动态包裹用户输入的关键词（如 URL 参数
q=React，页面中所有 “React” 需被语义化标记） - 文档引用片段里临时标出与当前段落强相关的术语（如教程中写 “检查
package.json中的 dependencies 字段”） - 代码示例中突出显示被修改/新增的行内部分（如
const value = <mark>42</mark>;），且该高亮需被读屏器识别为“上下文标记”，而非“强调重要性”
反例：按钮文案写 <mark>立即购买</mark>、整段警告文字套 mark、或在无上下文的 banner 里用它——这些都该用 strong 或 CSS 类。
动态高亮时最常踩的三个坑
用 JavaScript 做关键词高亮，直接 innerHTML.replace() 是最危险也最常见的写法。
立即学习“前端免费学习笔记（深入）”；
- 未转义正则特殊字符：用户搜
[a-z]，new RegExp(keyword)直接报错；必须先做keyword.replace(/[.*+?^${}()|[]\]/g, '\$&') - 未处理 HTML 结构：原始文本含
<code>console.log</code>，直接字符串替换会把标签撕开，导致 DOM 解析失败 - 忽略大小写还原：用
i标志匹配，但替换时硬写'<mark>$1</mark>'会丢失原大小写；应改用捕获组或String#replace()的回调函数保留原文本
安全做法是遍历文本节点（node.nodeType === 3），只在纯文本节点里创建 mark 元素并插入，跳过所有元素节点。
mark 的样式必须显式声明，不能依赖默认
浏览器默认样式（黄色背景 + 黑字）在以下环境会彻底消失：
- 用户启用阅读模式（Safari / Edge）
- 邮件客户端渲染 HTML（如 Outlook）
- 项目用了重置 CSS（如
* { background: transparent }）
生产环境至少要写死这四条：
mark {
background-color: #ffeb3b;
color: #212121;
padding: 0.1em 0.25em;
border-radius: 2px;
}深色模式下建议补充媒体查询；若用 background-color: transparent，别只写 background: none，它可能漏掉 background-image 等隐式值。
中文词边界和多关键词重叠问题
英文可用 匹配单词边界，但中文没有空格分隔，/搜索/gi 会误命中 “搜索引擎” 里的 “搜索”。
- 缓解方案：用 Unicode 断言模拟边界，例如
(? - 多关键词（如 “JavaScript” 和 “Script”）同时高亮时，必须按长度从长到短排序匹配，否则短词会切进已闭合的
mark内部 - 相邻
<mark>a</mark><mark>b</mark>渲染为两个独立块，不连贯；连续高亮应合并为一个<mark>ab</mark>
真正难的从来不是怎么写 <mark></mark>，而是判断哪段文本值得被它“认领”——语义一旦错配，后续所有样式、无障碍、SEO 优化都会失效。
