如何用String.prototype.normalize解决特殊Unicode字符导致的字符串匹配失败

normalize能解决字符串匹配失败，是因为Unicode中同一字符（如é）存在预组合形式（U+00E9）和分解形式（e+U+0301）两种合法编码，JavaScript的===或includes()逐码点比较，不归一化则判为不同；调用normalize()（默认NFC）可统一编码形式，使逻辑相等的字符串字节层面也一致。

为什么 normalize 能解决看似相同的字符串匹配失败？

因为同一个字符（比如带重音的 é）在 Unicode 中可能有多种合法编码形式：一种是单个预组合字符 'u00e9'（U+00E9），另一种是基础字符 'e' 加组合变音符 'u0301'（U+0301）。JavaScript 的 === 或 .includes() 会逐码点比较，两者不等价就直接判为不同。

调用 normalize() 可将不同编码形式统一为标准形式（默认是 'NFC'），让逻辑上“相同”的字符串在字节层面也一致。

normalize() 的四种形式怎么选？

实际项目中几乎只用 'NFC' 和 'NFD'：

• 'NFC'（默认）：把预组合字符优先保留，组合变音符尽量合并。适合显示、存储、常规匹配 —— 大多数输入法、浏览器 API 返回的文本天然倾向 NFC。
• 'NFD'：强制拆解所有预组合字符为基字符 + 组合标记。适合需要单独处理重音、做模糊搜索或正则过滤的场景（比如忽略重音匹配 a 和 á）。
• 'NFKC'/'NFKD'：还会做兼容性映射（如全角 ASCII → 半角、上标数字 → 普通数字），容易引发意外转换，除非明确需要兼容性处理，否则避开。

匹配前必须两端都 normalize

只 normalize 待查字符串或只 normalize 模式串，照样会失败。常见错误：

• 从用户输入框取值后 .normalize() 了，但数据库里存的是未 normalize 的原始值；
• 用 new RegExp(pattern.normalize())，却忘了 str.normalize() 再去 .match()；
• 前端 normalize 后发给后端，后端没 normalize 就直接查库（尤其 MySQL 的 utf8mb4 默认不 normalize）。

正确做法：确保参与比较的双方使用同一 normalize 形式，且最好在数据流入系统时就统一归一化（比如入库前 .normalize('NFC')）。

性能和边界要注意什么？

normalize() 不是免费的，对长文本或高频调用需留意：

• 它会创建新字符串，频繁调用可能触发 GC；短字符串（
• 不是所有环境都支持：IE 完全不支持，Node.js 早于 v12 的版本仅部分支持；可用 typeof ''.normalize === 'function' 检测；
• 某些罕见字符（如某些印度语系组合）在不同引擎中 normalize 行为略有差异，若涉及多语言严格校验，建议锁定 Node.js 版本并加测试用例。

真正容易被忽略的是：normalize 并不能修复已损坏的数据。如果历史数据混杂 NFC/NFD，靠运行时 normalize 只能缓解，彻底解决得批量清洗。