Intl.Segmenter 是浏览器原生支持的 Unicode 文本分段 API，按 locale 和 granularity（word/grapheme）精准分词，提升搜索建议效率；需检测兼容性并降级，避免长文本阻塞，结合语义加权优化匹配。
Intl.Segmenter 是浏览器原生支持的、符合 Unicode 标准的文本分段 API，它能按语言语境准确切分字词（如中文词、日文假名+汉字混合单元、英文连字符词等），比正则或空格分割更可靠。用于搜索建议场景时，它可提前将用户输入精准拆解为语义单元，减少后续匹配计算量，从而提升响应速度。
用 Segmenter 获取符合语言习惯的分词结果
不同语言的“词”边界差异很大：中文无空格，英文靠空格但存在 hyphenated-word，泰语/缅甸语甚至无显式分隔符。Intl.Segmenter 会依据 locale 和 granularity 自动适配：
- granularity: 'word' —— 按语义词切分（如中文单字/多字词、日文动词词干、英文带撇号的 don't）
- granularity: 'grapheme' —— 按用户感知的“字符”切分（处理 emoji 组合、带音标变音符号的字母）
- 指定 locale（如 'zh-CN'、'ja-JP'、'th-TH'）才能激活对应语言规则，不传 locale 可能回退到通用逻辑，精度下降
示例：对输入 "iPhone 15 Pro" 使用 en-US locale 分词，会得到 ["iPhone", "15", "Pro"] 而非 ["i", "Phone", ...]；对 "微信小程序" 使用 zh-CN locale，倾向输出 ["微信", "小程序"] 而非逐字切分。
预处理阶段调用 Segmenter 提升匹配效率
搜索建议通常需在用户输入过程中实时匹配已有词条。若每次都在原始字符串上做模糊匹配（如 indexOf、fuzzy-search），性能随词库增大而线性下降。改用分词后索引可显著加速：
- 对词库中每个条目（如商品名、标签名），预先用对应 locale 的 Segmenter 切分为 word 数组，并存入倒排索引（如 Map<string, Set<id>>）
- 用户输入时，同样用相同 locale 分词，只查询这些词对应的 id 集合，再取交集或加权合并
- 避免运行时重复分词：缓存 Segmenter 实例（new Intl.Segmenter(locale, {granularity: 'word'}) 开销小，但频繁新建仍不必要）
注意边界情况与降级策略
Segmenter 在部分旧版浏览器（如 Safari ≤16.4、某些安卓 WebView）中不可用，且对极少数 locale（如某些非洲语言）支持有限：
- 检测支持性：
typeof Intl.Segmenter === 'function'，不支持时回退到空格+简单正则（/[\s\u3000\uf900-\ufaff]+/切中文标点空格） - 长文本慎用：Segmenter 处理超长字符串（>10KB）可能阻塞主线程，建议限制输入长度或使用 Web Worker 异步分词
- 不要依赖分词结果绝对稳定：Unicode 标准更新可能导致同一字符串在不同引擎版本中分词微调，索引重建时保持 locale 和 granularity 一致即可
结合搜索逻辑做轻量级语义加权
分词本身不提供权重，但可辅助判断用户意图优先级：
- 首词分段结果（如输入“苹果”→["苹果"]）比尾词（如“手机苹果”→["手机","苹果"]）更可能代表核心查询目标
- 数字、年份类词（如“2024”、“iOS 18”）单独成段时，可触发版本/时间筛选逻辑，跳过纯文本匹配路径
- 对分词后的每个 word，检查是否在停用词表中（如“的”、“and”、“de”），过滤后减少无效匹配
这种基于分段语义的轻量路由，能让搜索建议在毫秒级内收敛到高相关候选集，无需启动全文检索引擎。
