如何用 String.prototype.normalize 处理特殊 Unicode 字符导致的字符串匹配失败
先来看一个典型的场景：明明肉眼看着一模一样的字符串，用 === 或者 .includes() 去比较，结果却返回 false。这往往不是代码逻辑错了，而是 Unicode 编码在“暗中作祟”。
为什么 normalize 能解决看似相同的字符串匹配失败？
问题的根源在于，Unicode 为了兼容性和灵活性，允许同一个字符存在多种合法的编码形式。就拿带重音的字母 é 来说，它至少有两种“合法身份”：
- 预组合形式：一个独立的码点
'\u00e9'（U+00E9）。 - 分解形式：由基础字母
'e'加上一个组合变音符'\u0301'（U+0301）组合而成。
关键在于，Ja vaScript 的字符串比较是逐码点进行的。对于引擎来说，'\u00e9' 和 'e\u0301' 就是两个完全不同的字节序列，所以 === 会毫不犹豫地判定它们不相等。
而 String.prototype.normalize() 方法，正是为了解决这种“逻辑相同，编码不同”的混乱而生的。调用它，可以将字符串转换为指定的 Unicode 规范化形式（默认是 'NFC'），从而确保含义相同的字符串，在底层字节表示上也保持一致。
normalize() 的四种形式怎么选？
规范化形式有四种，但实际开发中，'NFC' 和 'NFD' 基本覆盖了绝大多数场景。
'NFC'（Normalization Form Canonical Composition）：这是默认选项，也是推荐的首选。它会尝试将字符“组合”起来，优先保留预组合字符。简单来说，它让文本更紧凑。绝大多数现代输入法、浏览器API返回的文本，本身就倾向于NFC形式。因此，它非常适合用于显示、存储以及常规的字符串匹配。'NFD'（Normalization Form Canonical Decomposition）：它的策略正好相反，强制把所有预组合字符“拆解”成基字符加上组合标记。当你需要剥离重音进行模糊搜索（比如让a能匹配到á），或者基于字符基元进行处理时，NFD就派上了用场。'NFKC'与'NFKD'：带“K”的这两种形式，除了进行规范组合或分解，还会执行“兼容性”映射。例如，把全角字母数字转换成半角，或者把上标数字“²”转换成普通数字“2”。这种转换有时会改变文本的语义或外观，容易引发意料之外的结果。除非业务场景明确要求（比如严格的搜索引擎索引），否则一般建议避开使用。
匹配前必须两端都 normalize
这是一个非常容易踩坑的地方：只归一化一方是无效的。你必须保证参与比较的双方都使用了相同的规范化形式。
看看这些常见的失误：
- 前端对用户输入进行了
.normalize()，但后端数据库里存储的历史数据是未经处理的原始混合编码。 - 用
new RegExp(pattern.normalize())创建了正则表达式，却忘了把目标字符串也.normalize()后再去匹配。 - 前端发送归一化后的数据给后端，后端直接拿它去查询数据库，而数据库（尤其是MySQL的utf8mb4字符集）默认并不执行Unicode规范化。
所以，最佳实践是什么？在数据进入系统的边界处就进行统一规范化。比如，在数据入库前，统一调用 .normalize('NFC') 处理一遍。这样，系统内部处理的就是一致的数据，能从根本上避免匹配失败的问题。
性能和边界要注意什么？
把 normalize() 当作万能钥匙的同时，也得了解它的成本和限制。
- 性能开销：
normalize()会创建一个新的字符串对象。对于短字符串或低频调用，这点开销微不足道。但如果是对超长文本（比如整篇文档）进行频繁的规范化操作，或者在高并发的服务中处理大量数据，就需要关注其可能带来的内存和GC压力。 - 环境兼容性：IE浏览器完全不支持此方法。Node.js 在 v12 之前的版本中也只是部分支持。稳妥的做法是在使用前进行特性检测：
if (typeof ''.normalize === 'function')。 - 行为一致性：对于某些极其复杂的字符序列（如部分印度语系文字的特定组合），不同Ja vaScript引擎的规范化结果可能存在细微差异。如果项目对多语言文本的严格一致性有极高要求，建议锁定运行时环境版本，并针对关键字符集编写详尽的测试用例。
最后，必须强调一个关键点：normalize() 是用于预防和统一问题的，而不是修复已损坏数据的“后悔药”。如果系统中已经混杂了大量NFC和NFD格式的历史数据，仅靠运行时的 normalize() 只能缓解新产生的问题。要彻底解决，还是得靠一次性的数据清洗和迁移，让整个数据池变得纯净、一致。
