NFC规范化可统一Unicode等价字符的不同编码形式，确保比较、存储、检索一致性；应在输入边界（如表单提交、API接收、文件读取）立即执行，避免部分字段处理或重复调用，并需端到端协同后端、数据库与检索系统。
使用 String.prototype.normalize('NFC') 是解决 Unicode 等价字符（如带重音符号的字母）在不同输入方式下产生不同码点序列问题的有效手段。它本身不改变字符语义，但统一底层编码表示，从而保障存储、比较、索引等操作的一致性。
为什么需要 NFC 规范化？
Unicode 允许同一个视觉字符有多种合法编码方式。例如：
-
"é"可以是单个预组合字符 U+00E9（LATIN SMALL LETTER E WITH ACUTE） - 也可以是基础字符
"e"（U+0065）加组合符"́"（U+0301，COMBINING ACUTE ACCENT）
两者显示相同，但字节序列不同，直接比较会返回 false，数据库可能存为两条不同记录，搜索也可能失败。
何时调用 normalize('NFC') 最有效？
应在文本进入系统“边界”时立即规范化，而不是等到查询或显示阶段：
- 用户提交表单后、存入数据库前
- API 接收 JSON 字符串后、解析业务逻辑前
- 读取外部文件（如 CSV、JSON）并准备入库时
避免在每次读取或渲染时重复调用——那会掩盖源头不一致问题，且增加无谓开销。
实际使用中的关键注意事项
不要只对部分字段做 normalize：如果用户名做了 NFC，但邮箱没做，联合查询或去重就可能出错。
注意浏览器与 Node.js 的默认行为差异：现代浏览器通常按 NFC 输入（如 macOS 输入法），但复制粘贴、旧系统、某些编辑器仍可能带 NFD 序列；Node.js 读取文件时完全保留原始字节，不做隐式归一化。
验证是否真正生效：可对比归一化前后长度或码点数组：
const str = "e\u0301"; // e + combining acute<br>console.log(str.length); // 2<br>console.log(str.normalize("NFC").length); // 1<br>console.log([...str].map(c => c.codePointAt(0).toString(16))); // ["65", "301"]<br>console.log([...str.normalize("NFC")].map(c => c.codePointAt(0).toString(16))); // ["e9"]
配合存储与检索的完整建议
仅前端 normalize 不够，需端到端协同：
- 后端接收后立刻 normalize，再校验、清洗、存库（推荐在 ORM 实体赋值或 DTO 绑定阶段处理）
- 数据库字段若支持 collation（如 MySQL 8.0+ 的
utf8mb4_0900_as_cs），可辅助大小写和重音敏感比较，但仍建议先 normalize 再存，降低依赖 - 全文检索（如 Elasticsearch）应确保分析器对输入文本做同等 normalization，或在 ingest pipeline 中添加
icu_normalizerfilter
不复杂但容易忽略：一次 normalize，换来长期数据可比性与稳定性。
