中文关键词不能用\b匹配单词边界，因为\b只识别ASCII字母、数字和下划线边界，对中文无效，会导致“服务器”等语义断裂；须用Unicode字符类模拟“前后非汉字”边界，并注意排序去重、文本节点遍历替换及mark样式显式声明。
中文关键词为什么不能用\b匹配单词边界
因为\b只识别 ASCII 字母、数字和下划线的边界，对中文完全无效。搜“服务”，/\b服务\b/gi会把“服务器”“微服务”里的“服务”也切出来，语义断裂、阅读混乱。这不是正则写错了，是\b根本没在中文里起作用。
必须换一套边界逻辑：用 Unicode 字符类模拟“前后非汉字”的上下文。实际中推荐这个正则模式：/(?——前面不是汉字或开头，后面不是汉字或结尾，才能匹配。
- 注意
^和$要保留，否则段首/段尾关键词会漏掉 -
[^\u4e00-\u9fa5]覆盖标点、空格、英文字母、数字，但不包括换行符；如需兼容换行，加\s进去 - 该方案不解决“复合词”（如“微服务”），但能挡住 90% 的误匹配
多关键词高亮时顺序错乱导致嵌套失效
同时高亮“JavaScript”和“Script”，如果先处理短词，就会出现<mark>Java<mark>Script</mark></mark>这种非法嵌套。浏览器虽会自动展平为两个独立mark，但 DOM 结构已损坏：CSS 样式错位、读屏器播报重复、textContent提取失真。
正确做法是关键词数组按长度降序排列后再遍历：keywords.sort((a, b) => b.length - a.length)。这样“JavaScript”优先匹配，剩下“Script”就再也找不到可匹配位置了。
立即学习“前端免费学习笔记（深入）”；
- 中文词同样适用：若关键词含“人工智能”和“智能”，必须先匹配长的
- 排序前先去重，避免相同长度词反复触发 replaceChild
- 别在每次高亮时都重新 sort()，应在初始化阶段一次性排好
直接操作 innerHTML 替换中文关键词的三大翻车点
写el.innerHTML = el.innerHTML.replace(/服务/g, '<mark>服务</mark>')看着简单，但在中文场景下极易出事：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用户搜“<script>”，没转义就拼进字符串 → XSS 执行</script>
- 原文是
<p>这是服务端逻辑</p>，正则跨标签匹配 → 变成<p>这是<mark>服务</mark>端逻辑</p>，DOM 解析失败 - 关键词含正则元字符，比如搜“1+1”，
/1+1/g被当正则语法 → 报SyntaxError
安全路径只有一条：遍历文本节点，只对node.nodeType === 3的内容做textContent.replace()，再用document.createElement('mark')包裹后调node.parentNode.replaceChild()。
深色模式与 Outlook 下 样式消失的根本原因
mark在 Windows 高对比度模式、Outlook 邮件客户端、多数 CSS 重置库（如 normalize.css）里默认样式全被清空。不是你没写对，是这些环境主动屏蔽了 UA 样式。
生产环境必须显式声明三项：background-color、color、padding。只写background不行，它不覆盖background-image；只写background-color也不行，没color可能导致黑底黑字。
- 推荐组合：
mark { background-color: #ffeb3b; color: #212121; padding: 0.1em 0.25em; } - 深色模式补一句：
@media (prefers-color-scheme: dark) { mark { background-color: #ffca28; color: #121212; } } - 别依赖
border-radius来“美化”，它在 Outlook 里照样失效；padding才是边缘柔和的关键
中文高亮最麻烦的不是匹配，是边界判断和样式兜底——前者决定语义是否准确，后者决定用户到底看不看得见。
