string.prototype.normalize 能解决 unicode 匹配失败，因其将合成字符（如 u+00e9）和组合字符（如 "e"+u+0301）统一为标准形式（默认 nfc），使逻辑等价字符串字节层面一致。
为什么 String.prototype.normalize 能解决 Unicode 匹配失败
JavaScript 中两个看起来一模一样的字符串，用 === 或正则匹配却返回 false，大概率是它们的 Unicode 表示形式不同：一种是「合成字符」（如 "é" 直接用 U+00E9），另一种是「组合字符」（"e" + U+0301 重音符）。浏览器、输入法、复制粘贴都可能混入后者，导致 "café".includes("cafe") 返回 false。
而 normalize() 可将不同表示统一为标准形式（默认 "NFC"），让逻辑等价的字符串在字节层面也一致。
normalize() 的四种形式选哪个
实际开发中只用关注两种：
-
"NFC"（默认）：把能合成的字符尽量合成，比如"e\u0301"→"é"。适合显示、存储、常规比较 -
"NFD"：完全拆解为基字符 + 组合标记，比如"é"→"e\u0301"。适合需要精确控制重音、做音标分析或某些国际化排序
别用 "NFKC" / "NFKD" —— 它们会做兼容性转换（如全角 ASCII → 半角、上标数字 → 普通数字），可能把 "①" 变成 "1"，破坏原始语义。
匹配前必须两端都 normalize
只对搜索目标调用 normalize() 不够，被搜索文本也得同步处理，否则还是不等价。常见错误写法：
// ❌ 错误：只 normalize 模式，text 仍是组合形式 const text = "cafe\u0301"; const pattern = "café".normalize(); text.includes(pattern); // false
正确做法是统一 normalize 后再比：
// ✅ 正确：两端都走 NFC const text = "cafe\u0301"; const pattern = "café"; text.normalize() === pattern.normalize(); // true /case/.test(text.normalize()); // true（如果 pattern 是正则，也要 normalize 后构建）
注意：正则字面量无法动态 normalize，得用 new RegExp(pattern.normalize()) 构造。
性能和兼容性要注意什么
normalize() 在现代引擎里很快，但频繁调用仍要留意：
- 避免在循环内反复对同一字符串调用
normalize()，提前缓存结果 - IE 完全不支持，Node.js 早于 v4 也不支持；若需兼容，用
unorm等 polyfill（但注意 polyfill 的 NFC 实现未必 100% 与原生一致） - 某些罕见字符（如某些阿拉伯变体或历史文字）在不同引擎 normalize 行为略有差异，关键业务建议加单元测试覆盖实际用例
最常被忽略的是：normalize 不解决大小写问题，也不处理零宽空格、软连字符等不可见控制符——那些得靠 trim()、正则 /[\u200B-\u200D\uFEFF]/g 单独清理。
