Intl.Segmenter 不能直接替代正则高亮，因为它只按语言规则切分语义单元，不提供搜索能力；需自行实现匹配逻辑，并基于词元原始索引生成高亮，避免偏移错位。
Intl.Segmenter 为什么不能直接替代正则高亮
因为 Intl.Segmenter 本身不提供“搜索”能力，它只负责按语言规则把文本切分成语义单元（如词、字、句子）。你仍需自己做匹配逻辑，而它的价值在于：避免用 .split(/\s+/) 或 .match(/\w+/g) 这类粗暴切分导致的多语言失效问题。比如日语没有空格，中文词边界模糊，韩语有连写变体——这些都会让传统正则高亮漏匹配或错切分。
用 Segmenter 获取真实词元再做 indexOf 匹配
核心思路是：先用 Intl.Segmenter 把文档文本和搜索关键词都归一化为词元数组，再基于词元位置映射回原始字符串索引，最后生成高亮 HTML。注意不是拿词元去 includes()，而是要保留原始偏移量。
- 创建 segmenter 实例时必须指定
locale和{ granularity: 'word' }，否则默认是'grapheme'（字素），对中文/日语无效 - 调用
segmenter.segment(text)返回的是SegmentIterator，需遍历并收集{ segment, index, input }三元组，index是该词在原文中的起始 UTF-16 索引 - 对搜索词也做同样处理，但要注意：用户输入的关键词可能跨词（如搜“微信支付”，实际是两个词元），此时需用滑动窗口比对连续词元序列，而非单个词元等值匹配
const seg = new Intl.Segmenter('zh-CN', { granularity: 'word' });
const segments = [...seg.segment('微信支付很便捷')].map(s => ({ word: s.segment, start: s.index }));
// → [{ word: '微信', start: 0 }, { word: '支付', start: 2 }, { word: '很', start: 4 }, ...]
高亮时必须用原始字符串索引，不能用词元数组索引
常见错误是把匹配到的词元下标（如第 2 个词）直接当成原文位置，但词元长度不等（“Hello” vs “こんにちは”），会导致 innerHTML 插入错位。正确做法是记录每个词元的 s.index 和 s.segment.length，算出闭区间 [start, start + segment.length)，再用 String.prototype.slice() 截取并包裹 <mark>。
- 不要修改原始文本内容（比如 replace 时用正则全局匹配），否则会破坏后续 segmenter 对剩余文本的偏移计算
- 若需支持大小写不敏感，应在分词前统一转小写，但保存原始大小写的
segment和index用于最终高亮 - 遇到富文本（含 HTML 标签）时，先用
textContent提取纯文本分词，再将匹配结果映射回带标签的 HTML 字符串——这步需用Range或手动解析标签边界，否则<span>微信</span>会被切碎
性能和边界情况必须手动兜底
Intl.Segmenter 在 Safari 14.1+ 和 Chrome 85+ 支持良好，但 Node.js 仅从 19.2 开始内置，且部分 locale（如 'ja-JP'）在旧版 Chrome 中 fallback 到 grapheme 级别。更麻烦的是：它不处理停用词、词形还原或同义词，搜“running”不会匹配“ran”。
- 对英文建议组合使用
segmenter+FlexSearch等轻量索引库，而非纯前端实时分词匹配 - 用户输入为空格或标点时，
segmenter.segment(' ')可能返回空迭代器，需提前过滤掉零长词元 - 某些语言（如泰语、缅甸语）的分词规则尚未被所有浏览器完全实现，可加降级逻辑：捕获
RangeError后改用空格+标点切分，并打 warning 日志
真正难的从来不是调用 new Intl.Segmenter() 那一行，而是怎么把词元位置、DOM 结构、用户输入意图三者严丝合缝对齐——尤其当页面有动态渲染、编辑态切换或 SSR/CSR 混合时，分词上下文稍有不一致，高亮就会漂移。
