intl.segmenter 基于 unicode uax #29 规则提供精准语义分段，返回 utf-16 索引的闭区间 [start, end)，避免正则断句错误与 emoji/代理对索引偏移，需用 array.from 展开 segment 并归一化计算 end。
Intl.Segmenter 本身不提供“索引算法”，它只返回带 index 的语义段；所谓“符合语境习惯的断句索引”，本质是正确调用 segment() + 精确提取 index 和 segment 长度，再组合成闭区间 [start, end) —— 错一步，光标定位、朗读停顿、高亮都会偏移。
为什么 Intl.Segmenter("zh-CN", {granularity: "sentence"}) 比正则更可靠
正则 /[。！？.!?]+/ 会把「Mr. Smith」切成两段，也会漏掉中文省略号「……」、日文中点「・」、韩文问号「？」等合法句子边界。而 Intl.Segmenter 基于 Unicode UAX #29 Sentence Boundary 规则，结合 locale 数据自动识别：
- 中文：全角句号「。」、叹号「！」、问号「？」、省略号「……」（U+2026）
- 日文：「。」「！」「？」及英文标点（在
ja-JP下会结合助词上下文判断是否真为句尾） - 英文：
Mr.、Dr.中的句点被识别为缩写，不触发断句 - 混排文本如
"你好！Hello. こんにちは？"能稳定切出 3 个句子，且每个segment.index精确指向原文 UTF-16 起始位置
segment() 返回的 index 是 UTF-16 索引，不是字符数
这是最容易踩的坑：遇到 emoji 或代理对（如 ?、??），String.prototype.length 和 index 不一致，直接用 str.slice(i, i + len) 会截断字形。
- 必须用
segment.index和segment.segment.length计算终点：end = segment.index + [...segment.segment].length（展开为数组可安全计数） - 不要用
segment.segment.length直接加——因为 emoji 或 CJK 字符可能占 2 个 UTF-16 码元，但.length返回的是码元数，不是视觉字符数 - 验证方式：对
"a?b"调用segmenter.segment()，检查segment.index是否为 0、2、3，而非 0、1、2
如何构建可复用的断句索引数组
目标是得到形如 [{text: "第一句。", start: 0, end: 6}, {...}] 的结构，用于后续光标跳转或语音合成停顿。关键在遍历 segment() 迭代器时做归一化：
- 用
Array.from(segmenter.segment(text), s => ({ text: s.segment, start: s.index, end: s.index + [...s.segment].length })) - 避免提前
Array.from()后再处理——迭代器是懒执行的，大文本下能省内存 - 如果需支持 RTL（如阿拉伯语），
granularity: "sentence"仍有效，但注意end仍是逻辑顺序上的结束位置，无需反转 - 不要依赖
breakType字段：Chrome 和 Safari 对它的填充不一致，目前仅作参考，不可用于逻辑分支
locale 必须显式传入，不能靠 navigator.language 回退
浏览器不会自动 fallback 到最接近的 locale；传 "zh" 可能失败，"zh-CN" 或 "zh-TW" 才稳定。实操建议：
- 服务端渲染或 SSR 场景：从请求头
Accept-Language解析出首选 locale，降级到"en-US"而非空字符串 - 客户端动态切换：监听
i18n.onLocaleChanged重建Intl.Segmenter实例（它不可复用不同 locale） - 避免
new Intl.Segmenter(undefined, ...)：部分旧版 Safari 会抛RangeError - 测试时用真实多语言混合文本，例如：
"测试。Test. テスト。"，验证三段的start是否连续无重叠
真正难的不是调 API，而是接受 Intl.Segmenter 不解决语义——它给的只是边界，怎么用这些边界做光标吸附、TTS 停顿、或者和 DOM Range 对齐，每一步都要自己补足索引映射逻辑。尤其当文本含 HTML 标签时，textContent 和渲染后实际位置之间还有 layout 差异，这时候 index 就只是起点，不是终点。
