直接对字符串调用 normalize('NFC') 再匹配是最可靠方式，因同一字符可能有多种 Unicode 编码（如 é 为 U+00E9 或 e+U+0301），导致字节不同而匹配失败；需对所有参与比较的字符串统一 normalize('NFC')，避免仅单边处理，并注意返回新字符串、原串不变。
直接对字符串调用 normalize() 再匹配，是规避 Unicode 规范化干扰最可靠的方式。关键在于统一使用同一种规范化形式（通常是 NFC），让等价但编码不同的字符序列变成完全相同的字节序列。
为什么原始字符串匹配会出问题
同一个视觉字符可能有多种 Unicode 编码方式。例如：
- é 可以是单个预组字符
U+00E9（NFC 形式） - 也可以是
e + U+0301（基础字母 e 加上组合重音符，属于 NFD 形式）
这两个字符串在界面上看起来一模一样，但底层字节不同："é" !== "e\u0301"。正则匹配、includes()、indexOf() 等都会返回 false 或 -1。
统一用 normalize('NFC') 处理所有参与比较的字符串
NFC（Normalization Form C）是推荐的默认形式，它把可组合字符尽可能合并为预组字符，兼容性好、显示稳定。
- 匹配前，对目标字符串和搜索关键词都调用
.normalize('NFC') - 确保输入文本、用户输入、数据库读取内容、配置项等全部走一遍 normalize
- 避免只 normalize 一边 —— 比如只 normalize 用户输入却不 normalize 字典数据，依然会漏匹配
示例：
const text = "cafe\u0301"; // "café" in NFDconst keyword = "café"; // "café" in NFC
// ❌ 错误：未统一规范化
text.includes(keyword); // false
// ✅ 正确：两边都 NFC
text.normalize('NFC').includes(keyword.normalize('NFC')); // true
注意 normalize() 不改变原始字符串，需显式赋值或链式使用
normalize() 返回新字符串，原字符串不变。常见疏漏包括：
- 调用了
str.normalize()却没接住返回值 - 在正则中直接写
/abc/.test(str.normalize())，但忘记 normalize 搜索模式本身（如果模式里也含 Unicode 字符） - 后端返回 JSON 中的字符串未 normalize，前端直接拿来匹配
建议封装一个安全匹配函数：
function safeIncludes(str, search) {return str.normalize('NFC').includes(search.normalize('NFC'));
}
其他规范化形式的适用场景
NFD 把字符彻底拆解为基字 + 组合符，适合需要分析或过滤重音、变音符号的场景（比如拼音转换、忽略重音搜索）。但日常字符串匹配优先选 NFC：
-
NFKC和NFKD会做兼容性转换（如全角→半角、上标数字→普通数字），可能过度归一，导致语义变化 - 除非业务明确要求“1”和“¹”视为相同，否则不要用 K 系列形式
- 浏览器和主流 API（如
Intl.Collator）默认内部使用NFC，保持一致更稳妥
