前端怎样按语言边界切分用户文本

前端可以用 Intl.Segmenter 按字素、词或句子边界切分文本：给构造器传入内容语言或语言优先列表，用 granularity 指定粒度，再遍历 segment(text) 返回的片段。不要用空格切分替代中文分词，也不要把字符串的 length 当成用户看到的字符数。

平台文档：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Segmenter；国际化标准：https://tc39.es/ecma402/#segmenter-objects。本文只讨论粒度和语言选择，不把边界切分当成语义理解、关键词提取或领域词典系统。以下代码未在浏览器中实测。

先把“切分”对应到一个明确用途

一个评论输入框可能需要按可感知字符计数，阅读页可能需要整理候选词片段，而段落工具可能需要按句子处理。三者的数据结构看起来相似，边界含义却不同。比较稳妥的组织方式是先选任务粒度，再决定内容语言，最后保留原始片段，按业务需要派生词列表。

三个粒度为什么不能互换

grapheme 适合处理组合字符、部分表情序列等字素簇。JavaScript 的 split("") 按代码单元拆分，字符串展开通常按码点遍历，两者都不能普遍替代字素边界。字素簇也不是字形渲染宽度，一个片段占多少像素仍取决于字体和布局。

word 会返回词片段，也会返回空白、标点等片段。需要词列表时，应使用 isWordLike 选择，而不是认为每条返回记录都是一个词。sentence 更适合句子边界，但不承诺理解缩写、专业材料和混合语言中的全部语义。

语言参数是偏好，不是自动识别语言

构造器可以接收 "zh-CN"，也可以接收 ["zh-CN", "en"]。后者是语言协商的优先列表，不表示先用中文切一遍，再用英文切一遍。省略语言会使用运行环境的默认选择，不能因此声称 API 已识别用户文本语言。

内容语言已知时优先使用内容语言；界面语言只能作为业务上明确接受的默认值。混合语言文本也不会因为传入一个数组，就自动给每一小段分配一种语言。如果产品需要逐段语言识别，应将它视为独立问题。

// 观察语言支持和实际采用的参数，不把默认语言当作内容检测结果
if (typeof Intl !== "undefined" && typeof Intl.Segmenter === "function") {
  const requested = ["zh-CN", "en"];
  console.log(Intl.Segmenter.supportedLocalesOf(requested));
  const segmenter = new Intl.Segmenter(requested, { granularity: "sentence" });
  console.log(segmenter.resolvedOptions());
}

supportedLocalesOf 用于了解请求标签中哪些无需回落到运行时默认语言即可支持；resolvedOptions() 用于读取实际协商结果和粒度。它们不证明某段文字的分词质量。非法语言标签可能导致 RangeError，产品应约束语言配置，并在调用边界处理异常。

保留文本和索引，再派生需要的列表

// 对调用方显式报错，不把空格切分冒充语言分词
function segmentText(text, locales, granularity = "grapheme") {
  if (typeof text !== "string") throw new TypeError("文本必须是字符串");
  if (!["grapheme", "word", "sentence"].includes(granularity)) {
    throw new RangeError("不支持的切分粒度");
  }
  if (typeof Intl === "undefined" || typeof Intl.Segmenter !== "function") {
    throw new Error("当前环境不支持 Intl.Segmenter");
  }

  // locales 可以是一个语言标签，也可以是按优先级排列的标签数组
  const segmenter = new Intl.Segmenter(locales, { granularity });
  const parts = Array.from(segmenter.segment(text), part => {
    const result = { text: part.segment, index: part.index };
    // 只有 word 粒度才读取词标记，避免把不存在的标记当成 false
    if (granularity === "word") result.isWordLike = part.isWordLike;
    return result;
  });
  return { options: segmenter.resolvedOptions(), parts };
}

// 演示材料包含组合音标和表情，输出仅供读者自行观察
const sample = "Cafe\u0301 你好 👩‍💻。继续阅读！";
try {
  const result = segmentText(sample, ["zh-CN", "en"], "word");
  console.log(result.options);
  console.log(result.parts);
  const words = result.parts.filter(part => part.isWordLike);
  console.log(words.map(part => part.text));

  // 完整片段可以还原原文；过滤后的词列表则不能
  console.log(result.parts.map(part => part.text).join("") === sample);
} catch (error) {
  console.error("文本切分不可用：", error.message);
}

函数把每条记录收敛为 text、index，以及 word 粒度下的 isWordLike。标准记录中的 input 表示原始输入，这里没有在每条业务记录中重复保存。index 是原字符串中的 UTF-16 代码单元偏移，不是字素序号；同一字符串上的 slice 可以使用这种偏移，但不能直接拿它当“第几个可见字符”。

示例的预期性质是：把完整 parts 的 text 按顺序连接，应还原 sample；只保留 isWordLike 的词列表会丢掉部分空白和标点。不要依赖本文为整段中文给出固定分词数组，语言数据和运行时实现可能造成具体边界差异。

不支持时如何处理，取决于功能是否必须精确

上面的函数在能力缺失时明确报错，让调用方决定禁用词统计、保留原文，还是引入经过项目选型的兼容实现。不能悄悄退回 split(" ") 后继续显示“准确分词”。按码点计数也只是另一种口径，不等于字素计数。

长文本不一定要立刻全部转换成数组。只做累计时可遍历 Segments；需要可复用结果列表时再物化。两种方式都仍需要处理文本本身，不应宣称它们没有内存或主线程成本。相同语言和粒度的多次调用，可以复用 Segmenter 实例，但要让缓存规模服从业务实际，而不是无限保存用户输入。

接入时可以照着这张速查表做选择

grapheme 是不是默认粒度？

是。仍建议在业务代码中显式写出粒度，使阅读者能看出功能采用的计数或切分口径。

为什么 word 的结果里还有空格？

它描述连续文本的完整边界，而不是只输出词。只有在确实需要舍弃非词片段时，才过滤 isWordLike；grapheme 和 sentence 记录不提供这个词标记。

指定 zh-CN 后为什么不是业务想要的词？

语言敏感的边界规则不等于行业词典。产品名、缩写或特定术语需要稳定规则时，应定义自己的补充策略，而不是反复更换语言标签碰运气。