Intl.Segmenter 如何按中文词边界截断摘要：word 粒度与多语言回退

搜索结果卡片通常只给两行摘要，但中文文本按字符数直接截断时，词语会被拦腰切开，英文和表情也可能留下半个单位。更稳妥的做法是让 Intl.Segmenter 按指定语言和 word 粒度返回边界，再把完整词段累加到目标长度以内。

需要“看起来像自然短句”的摘要时，先用 Intl.Segmenter 取得词段，再用 isWordLike 排除标点；运行环境不支持目标语言时，用 supportedLocalesOf 选择回退语言，而不是假设所有浏览器结果相同。

先把“截断 48 个字符”改成“保留完整词段”

假设卡片摘要上限是 48 个 JavaScript 字符。中文标题“浏览器缓存策略如何避免重复请求”按下标切开，视觉上不一定马上出错；但混入英文单词、连字符或 emoji 后，下标只表示 UTF-16 code unit 位置，并不代表读者认知上的边界。

交互上，这个组件需要两个结果：一是可直接展示的短文本，二是是否真的发生过截断的状态。把两者一起算出来，展开按钮才不会在短文本上误出现。

function truncateByWord(text, maxLength, locale = "zh-CN") {
  const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
  let result = "";
  let truncated = false;

  for (const part of segmenter.segment(text)) {
    if (result.length + part.segment.length > maxLength) {
      truncated = true;
      break;
    }
    result += part.segment;
  }

  return { text: result, truncated };
}

这里的调用链很短：truncateByWord 创建 Intl.Segmenter，再调用 segment() 逐段读取；一旦加入下一段会超过上限，就把 truncated 置为 true 并停止。注意 part.segment.length 仍然是字符串长度，它只负责容量计算，真正的边界由 Segmenter 提供。

用 isWordLike 处理标点、空格和混排文本

直接累加所有段，通常会把结尾标点也算进预算。更麻烦的是，中文、英文、数字之间的分段规则由语言环境决定，不能写一个正则就覆盖所有输入。对于摘要展示，可以保留原始空格和标点，但在“还剩很少空间”时优先回退到最后一个 isWordLike 为真的词段。

function collectWords(text, locale = "zh-CN") {
  const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
  return [...segmenter.segment(text)]
    .filter(part => part.isWordLike)
    .map(part => part.segment);
}

isWordLike 不是“这个词适不适合搜索”的判断，它只说明当前分段是否像词语或数字。标点仍然应该由展示层决定是否保留；例如标题末尾的“：”可能需要留下，但不应当被误当成一个可独立计数的词。

多语言回退要显式检查，不要把默认语言当成中文

页面可能同时处理中文、日文和英文摘要。Intl.Segmenter 在没有可用请求语言时会按运行时规则选择实际 locale，所以组件最好先检查目标语言，再决定是否构造分段器。

function chooseLocale(requested, fallback = "en") {
  const supported = Intl.Segmenter.supportedLocalesOf(requested);
  return supported[0] || fallback;
}

const locale = chooseLocale(["zh-CN", "en"]);
const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
console.log(segmenter.resolvedOptions());

官方接口保证 supportedLocalesOf 返回无需回退的请求语言子集，resolvedOptions() 则能让调试面板看到最终使用的 locale 和 granularity。两者配合后，测试可以覆盖“请求中文但运行时只提供英文”的情况。

兼容性和边界状态怎么验收

这个能力在现代浏览器中已较普遍，但组件不能把它当作永远存在。初始化时可用特性检测；不支持时，至少保留一个不会抛异常的字符级方案，并把摘要标记为“可能按字符截断”，不要悄悄声称已经按词处理。

function safeTruncate(text, maxLength, locale) {
  if (typeof Intl?.Segmenter === "function") {
    return truncateByWord(text, maxLength, locale);
  }
  return {
    text: text.slice(0, maxLength),
    truncated: text.length > maxLength
  };
}

验收时至少覆盖空字符串、短于上限的文本、中文英文混排、连续标点、emoji 和不支持语言。尤其要断言：短文本的 truncated 必须为 false；超长文本不能超过预算；回退实现不应阻塞卡片渲染。

相关问题

Intl.Segmenter 默认就是 word 粒度吗？

不是。默认粒度是 grapheme，需要明确传入 { granularity: "word" } 才按词处理。

为什么不用 split(" ") 截断中文？

中文通常没有空格分隔词，英文缩写、标点和混排文本也会让简单 split 失去边界信息。

isWordLike 能替代完整的中文分词系统吗？

不能。它适合界面截断和基础分段，不等于业务搜索、关键词抽取或领域分词。

回退到 slice 会不会切坏 emoji？

有可能。若回退场景必须保证用户感知字符完整，应再增加 grapheme 级方案或服务端预处理，而不是把 slice 当作等价实现。

把摘要组件做成可复查的小闭环

最终实现不在于把代码写得更长，而在于让边界清楚：Segmenter 负责分段，累加逻辑负责长度和截断状态，isWordLike 负责词段筛选，supportedLocalesOf 负责语言选择，特性检测负责降级。把这几个职责拆开后，设计稿里的“显示两行摘要”就能对应到可测试的状态，而不是依赖浏览器碰巧给出的结果。