intl.segmenter 不是分词器，而是基于 unicode 标准和 locale 的语言感知边界划分工具；对中日文仅按规则切字、词、句，不依赖模型或词典，无法处理语义分词与歧义消解。
Intl.Segmenter 不是分词器，它不做语义切分，只按 Unicode 标准做语言感知的边界划分；对中文、日文等无空格语言，它能识别字、词、句子边界，但结果取决于 locale 和 granularity 设置，不能替代 jieba 或 Kuromoji。
为什么 Intl.Segmenter 对中日文“看起来像分词”但实际不是
它底层依赖 ICU 的 BreakIterator，依据 Unicode UAX #29（Grapheme、Word、Sentence 边界规则）和 locale 特定数据（如 ja-JP 启用日文词边界规则），而非训练模型或词典。所以：
-
granularity: "word"在zh-CN下基本按字切（因中文 Unicode Word Boundary 规则极弱），但在ja-JP下可切出「食べる」「昨日」这类黏着语词干+助词组合 -
granularity: "sentence"能正确识别中文全角句号、日文「。」及英文句点后的断句，比正则/[。！？.!?]+/更可靠 - 不支持自定义词典、未登录词、歧义消解——比如「南京市长江大桥」在
zh-CN下仍会切成单字，不会识别「南京市」「长江大桥」
Intl.Segmenter 实际可用的中日文场景与参数搭配
真正能落地的，是轻量级、标准化、无需额外依赖的边界提取，比如富文本光标定位、朗读停顿、简单高亮。关键看 locale + granularity 组合：
- 日文词级切分：用
new Intl.Segmenter("ja-JP", {granularity: "word"})—— 它能区分「勉強する」中的「勉強」（名词）和「する」（动词），也能切开「東京都」中的「東京都」（专有名词整体） - 中日文混排断句：用
new Intl.Segmenter("zh-CN", {granularity: "sentence"})或"ja-JP"，可同时处理「你好！Hello. こんにちは！」→ 三个句子，且保留各语言标点 - 避免用
zh-CN+granularity: "word"做“中文分词”：Chrome/Firefox 当前实现下几乎等价于[...text]，Safari 更不稳定
常见错误与兼容性坑点
直接 new 一个就用，很容易掉进浏览器行为差异或预期错位的坑里：
- Edge 18 及更早版本不支持
Intl.Segmenter，需检查typeof Intl.Segmenter === "function"；Safari 14.1+ 才支持granularity: "word"（之前只支持 sentence/grapheme） - 传入非法 locale（如
"zh"而非"zh-CN"）会导致降级为en-US行为，中文变空格切分逻辑 - segment() 返回的是迭代器，不是数组：
Array.from(segmenter.segment("あいさつ"))得到的是{segment: "あ", index: 0, input: "あいさつ", isWordLike: true}类对象，别直接.map() - 性能敏感场景慎用：每个 segment 对象含完整元信息，大量文本（>10KB）反复调用可能比正则慢 2–3 倍，建议预热实例并复用
一个安全可用的封装示例
针对日文阅读辅助场景，提取词+句子边界混合处理：
const segWord = new Intl.Segmenter("ja-JP", {granularity: "word"});
const segSent = new Intl.Segmenter("ja-JP", {granularity: "sentence"});
function tokenizeJp(text) {
const sentences = [];
for (const sent of segSent.segment(text)) {
const words = [];
for (const word of segWord.segment(sent.segment)) {
if (word.isWordLike) words.push(word.segment);
}
sentences.push(words);
}
return sentences;
}
// tokenizeJp("今日は良い天気です。明日は雨でしょう。")
// → [["今日", "は", "良い", "天気", "です"], ["明日", "は", "雨", "でしょう"]]
注意：这个结果不是 NLP 意义上的分词，而是 ICU 规则下的可预测切分——它稳定、跨平台、零依赖，但也仅此而已。真要处理「行きます」→「行く」「ます」这样的活用分解，还是得上专门的日文形态分析库。
