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) 截取并包裹

处理富文本与大小写：先剥离，再映射

网页中待搜索内容常含 HTML 标签。直接对带标签字符串分词会污染边界（如把 你好 中的 当作词元）。必须分两步走：

• 用 element.textContent 提取纯文本，用于分词与匹配
• 将匹配到的原始字符串偏移区间（如 [24, 30)），通过正则或 DOM 遍历方式，映射回带标签的 HTML 字符串中对应位置，再插入
• 如需忽略大小写，统一在分词前调用 .toLocaleLowerCase()，但保存原始文本的 index 和 segment，确保高亮显示的是用户原输入样式

真正需要语义时，必须引入外部能力

当业务明确要求“把‘苹果’识别为水果而非公司”“把‘Python’识别为编程语言而非蛇”，Intl.Segmenter 已到极限。此时只有两条现实路径：

• 前端轻量语义层：集成 jieba-browser（WASM 版 jieba）或 lunr 配合中文分词预处理 pipeline，加载几 MB 词典，首次调用有延迟，适合离线知识库场景
• 服务端 NLP 协同：前端只传文本 ID 和关键词，后端调用 HanLP/LTP/百度 NLP API 返回带 offset 和 pos 的分词结果，前端专注渲染与交互，规避浏览器性能与兼容性风险