Intl.Segmenter 对中文分词基本无效，它按 Unicode UAX-29 规则切分为字、标点或 Emoji 单元，不识别语义词或句子边界，仅适用于光标移动、选区高亮等底层文本操作。
Intl.Segmenter 对中文分词基本无效
直接说结论：Intl.Segmenter 在中文场景下无法做语义分词，也不能可靠断句。它按 Unicode 文本分割算法（UAX-29）工作，对中文只按字、标点或 Emoji 边界切分，不识别词或句子边界。比如 "我喜欢编程" 会被切成 ["我", "喜", "欢", "编", "程"]，而非 ["我", "喜欢", "编程"] —— 这不是 bug，是设计使然。
它的定位是国际化文本“底层切分”，比如光标移动、选区高亮、语音合成停顿点，而非 NLP 任务。浏览器实现也明确不承诺支持中文分词逻辑。
用 segmenter.granularity === 'word' 统计“字数”或“标点数”可以，但别叫“词数”
如果你只是想统计用户输入的“视觉上可独立操作的单元”（如编辑器里双击选中的单位），Intl.Segmenter 配合 granularity: 'word' 是轻量可行的：
const seg = new Intl.Segmenter('zh-CN', { granularity: 'word' });
const input = 'Hello，你好！123';
const count = [...seg.segment(input)].length; // → 8（H/e/l/l/o/，/你好/！/123）
-
'word'在中文中实际切出的是 UAX-29 定义的“扩展字汇单元”（Extended Grapheme Cluster），基本等价于“用户感知的一个字或符号”，含汉字、全角标点、emoji 序列 - 结果不含空格；半角空格会被归入前/后 word，全角空格会单独成段
- 不同浏览器对连字符、数字+单位（如“10kg”）的处理略有差异，不要依赖其做格式校验
真正需要中文分词或断句时，必须换方案
浏览器原生不提供语义分词能力。替代路径只有两条，且都绕不开外部数据或模型：
- 前端轻量方案：用
jieba-browser或lunr+ 预置词典。前者是 Python jieba 的 WASM 移植，支持基础分词和词性；后者适合搜索场景，需自己构建中文分词 pipeline - 服务端兜底：把文本发到后端 NLP API（如 HanLP、LTP、百度 NLP），返回
{word: string, pos: string, offset: number}结构。前端只做渲染和交互，避免在浏览器跑大模型 - 注意：所有纯 JS 分词库都会加载几 MB 词典文件，首次调用有延迟；WASM 版本需启用
crossorigin和 MIME 类型支持
断句（sentence segmentation）比分词更危险——Intl.Segmenter 会误切“。”“！”之外的所有情况
Intl.Segmenter 设置 granularity: 'sentence' 仅识别 Unicode 定义的“句子终结符”（UAX-29 的 Sentence_Terminal），即 . ! ? 。！？ 等，但完全忽略中文常见的无标点句尾、省略号、引号闭合、括号嵌套等。例如：
const seg = new Intl.Segmenter('zh-CN', { granularity: 'sentence' });
[...seg.segment('他说：“你好”然后走了')].map(s => s.segment);
// → ['他说：“你好”然后走了']（整句没被切开）
- 它不会识别「」、『』、”’ 等引号内的结束，也不会处理「……」「——」等破折号或省略号结尾
- 对英文混排文本（如「API v2.3.0 发布了！」）可能把
v2.3.0错误当作句末 - 如需可靠断句，必须用规则引擎（如基于正则的启发式匹配）或专用模型（如 spaCy 的 zh-core-web-sm），不能依赖
Intl.Segmenter
最常被忽略的一点：即使你只想要“看起来像分词”的粗粒度展示，也要先明确用户真实需求——是用于字数统计、光标导航、还是搜索索引？选错层级，后续所有优化都是徒劳。
