Intl.Segmenter 仅按 Unicode UAX-29 规则进行语言感知的边界切分，不支持语义识别；它提供可靠的基础词元边界（如汉字、emoji、连写数字单位），用于精准搜索高亮与偏移映射，而非替代语义分词。
Intl.Segmenter 本身不支持语义识别，它只按 Unicode UAX-29 规则做语言感知的边界切分，无法理解“微信支付”是一个复合词、“南京市长江大桥”应切分为地名+桥梁名。所谓“语义识别的断词索引与高亮增强”，必须由 Segmenter 提供**可靠的基础词元边界**，再叠加前端匹配逻辑与偏移映射——不是让 Segmenter 做语义，而是让它避免把语义搞错。
明确 Segmenter 的能力边界：它切的是“可编辑单元”，不是“语义词”
对中文，new Intl.Segmenter('zh-CN', { granularity: 'word' }) 实际返回的是扩展字素簇（Extended Grapheme Cluster），基本等价于用户双击选中的单位：一个汉字、一个全角标点、一个 emoji，或连写的数字+单位（如“10kg”在部分浏览器中视为一词）。它不会把“苹果手机”切出“苹果”和“手机”，但也不会错误地把“微信支付”切成“微”“信”“支”“付”。这个“不乱切”，就是它对搜索高亮的最大价值。
- 日文（
ja-JP）下效果更明显：能区分「食べる」中的词干「食べ」和动词结尾「る」，也能保留「東京都」整体不被拆开 - 中日混排文本中，用
granularity: 'sentence'可同时识别「。」「！」「?」「.」「!」「?」，比正则/[。！？.!?]+/更鲁棒 - 不要传
'zh'这类不完整 locale，否则可能降级为英文空格切分逻辑，导致中文全崩
构建词元索引：保留原始位置，拒绝数组下标幻觉
高亮错位的根源，是把“第 3 个词元”当成“原文第 3 个字符”。正确做法是遍历 segmenter.segment(text) 返回的迭代器，显式记录每个词元的 segment（内容）、index（UTF-16 起始偏移）、segment.length（长度）：
- 对文档文本执行：
Array.from(segmenter.segment(content)).map(({ segment, index }) => ({ word: segment, start: index })) - 对搜索关键词同样分词，并提取其词元数组；若搜“微信支付”，得到
['微信', '支付']，就需滑动窗口匹配连续两个词元，而非单个includes() - 匹配成功后，根据首个词元的
start和总长度算出闭区间[start, start + totalLength)，再用content.slice(start, end)截取并包裹<mark></mark>
处理富文本与大小写：先剥离，再映射
网页中待搜索内容常含 HTML 标签。直接对带标签字符串分词会污染边界（如把 <span>你好</span> 中的 当作词元）。必须分两步走：
- 用
element.textContent提取纯文本，用于分词与匹配 - 将匹配到的原始字符串偏移区间（如
[24, 30)），通过正则或 DOM 遍历方式，映射回带标签的 HTML 字符串中对应位置，再插入<mark></mark> - 如需忽略大小写，统一在分词前调用
.toLocaleLowerCase()，但保存原始文本的index和segment，确保高亮显示的是用户原输入样式
真正需要语义时，必须引入外部能力
当业务明确要求“把‘苹果’识别为水果而非公司”“把‘Python’识别为编程语言而非蛇”，Intl.Segmenter 已到极限。此时只有两条现实路径：
-
前端轻量语义层：集成
jieba-browser（WASM 版 jieba）或lunr配合中文分词预处理 pipeline，加载几 MB 词典，首次调用有延迟，适合离线知识库场景 -
服务端 NLP 协同：前端只传文本 ID 和关键词，后端调用 HanLP/LTP/百度 NLP API 返回带
offset和pos的分词结果，前端专注渲染与交互，规避浏览器性能与兼容性风险
