normalize()本身不提升召回率，关键在于统一查询词、索引字段和用户输入三端的Unicode表示形式，否则因é等字符存在预组合与分解两种编码，导致逐码点比较时漏匹配。
直接对原始文本调用 normalize() 本身不能提升召回率，关键在于统一参与检索的**所有文本端**（查询词、索引字段、用户输入）的 Unicode 表示形式。否则，逻辑上相同的字符（如 é）因编码不同被当作两个完全不同的字符串，导致漏匹配。
为什么不 normalize 就会丢结果
Unicode 允许同一个视觉字符有多种合法编码方式：
- 预组合形式：
'\u00e9'（单个码点 “é”） - 分解形式：
'e\u0301'（字母 “e” + 组合重音符 “́”）
JavaScript 的 ===、.includes()、正则匹配等操作逐码点比较。只要两端形式不一致，哪怕人眼看一模一样，也会判为不匹配 —— 这就是召回率下降的根源。
必须两端同时 normalize 才有效
只处理一边毫无意义，常见失效场景包括：
- 前端对用户输入
.normalize('NFC')，但后端数据库字段是原始未归一化的值 - 用
new RegExp(keyword.normalize())构造正则，却没对目标文本也.normalize() - ES 或 MySQL 全文索引建在未 normalize 的字段上，而查询时才 normalize 查询词
正确做法：在数据写入环节就统一归一化。例如入库前执行 text.normalize('NFC')，确保所有索引项和后续查询都基于同一标准形式。
NFC 还是 NFD？优先选 NFC
实际搜索场景中，NFC 是默认且最稳妥的选择：
- 绝大多数输入法、浏览器 API、现代编辑器输出默认就是 NFC 形式
- NFC 保留预组合字符，更贴近人类阅读习惯，适合显示、存储与常规精确匹配
- NFD 虽便于做“忽略重音”的模糊搜索（比如把 á、à、a 都转成 a 再比），但需额外逻辑，且可能破坏原始语义（如某些语言中组合顺序敏感）
除非你明确需要重音剥离类搜索，否则不要用 NFD；NFKC/NFKD 因涉及兼容性转换（如全角→半角、上标→普通数字），容易引发意外替换，应避免用于检索主流程。
配合其他策略效果更稳
normalize 解决的是“同字异码”问题，但它不解决拼写错误、同义词或语义相似性。要真正提升召回，还需叠加：
- 建立倒排索引时，对字段值统一
.normalize('NFC')后再分词 - 查询时，对用户输入同样
.normalize('NFC')，再进行分词或模式匹配 - 对专有名词、人名、地名等，可额外维护别名映射表（如 “Microsoft” ↔ “MSFT”）
- 必要时引入轻量级纠错（如编辑距离 ≤1 的候选扩展）或同义词扩展（如 “car” → “automobile”）
normalize 是全文检索稳定性的底层基础，不是万能药，但缺了它，很多看似合理的搜索都会静默失败。
