用 normalize('NFC') 解决“多合一”字符等值判定，即统一合成形（如\u00E9）与分解形（如e+\u0301）为相同码点序列，确保===、includes()、正则等逐码点比对准确；两端必须同步归一化，且优先选用NFC而非易改语义的NFKC/NFKD。
用 normalize() 解决“多合一”字符的等值判定，核心在于统一 Unicode 的不同编码形式——比如 “é” 既可以是单个预组合字符 \u00E9，也可以是 “e” 加组合重音符 \u0301。JavaScript 的 ===、.includes() 或正则匹配，都是逐码点比对，不归一化就必然判为不等。调用 .normalize('NFC') 后，两者都转成 \u00E9，字节一致，判定自然准确。
理解“多合一”问题的本质
所谓“多合一”，指 Unicode 中一个逻辑字符对应多种合法编码方式：
-
合成形式（NFC）：如
"ñ"直接用\u00F1表示； -
分解形式（NFD）：如
"n\u0303"（n + 组合波浪符），视觉完全一样但由两个码点构成。
用户输入、复制粘贴、不同系统导出的文本，常混用这两种形式。看似相同的字符串，在 JS 内部其实是不同的码点序列，直接比较必失败。
只用 NFC 就够了，别碰 NFKC/NFKD
日常开发中，'NFC' 是默认且最安全的选择：
- 它把能合成的尽量合成，结果直观、可读性强，适合显示、存储和常规比对；
-
'NFD'只在特殊场景需要（如剥离重音做模糊搜索）； -
'NFKC'和'NFKD'会做兼容性转换（如全角数字 → 半角、上标① → 普通1），可能意外改变语义，除非明确要兼容处理，否则避开。
两端必须同时 normalize
只处理一边等于白忙——常见错误包括：
- 前端对用户输入调用了
.normalize()，但后端查数据库时没对字段做同样处理； - 用
new RegExp(pattern.normalize())构造正则，却忘了先对目标字符串也.normalize()； - 入库前未统一归一化，导致同一词在库中存着 NFC 和 NFD 两种形式。
正确做法：所有参与比对的字符串（输入值、配置项、数据库字段、API 返回值）应在进入比对逻辑前，统一用 .normalize('NFC') 处理。
实际写法示例
避免动态正则陷阱：
// ✅ 安全比对（字符串）
const a = "cafe\u0301"; // 分解式 é
const b = "café"; // 合成式 é
a.normalize() === b.normalize(); // true
// ✅ 安全正则（注意 new RegExp + normalize）
const pattern = "jalapeño";
const re = new RegExp(pattern.normalize(), "i");
re.test("Jalape\u0303o".normalize()); // true
// ✅ 入库前归一化（Node.js 示例）
db.insert({ name: userInput.trim().normalize('NFC') });
