String.prototype.normalize('NFKD') 是深度去重与匹配的关键预处理步骤，通过兼容分解统一Unicode等价字符（如带音调字母、全角数字、罗马数字等），提升去重准确率和模糊匹配容错性。
String.prototype.normalize('NFKD') 本身不直接实现“深度去重与匹配”，但它是一个关键预处理步骤，能显著提升文本去重和匹配的准确率——尤其在处理 Unicode 等价字符（如带音调字母、全角/半角符号、上标数字、兼容汉字变体等）时。
为什么 NFKD 是深度去重的前提
NFKD（Normalization Form KD）将字符“兼容分解”：把一个复合字符拆成基础字符 + 组合标记，并将兼容字符（如全角ASCII、上标²、罗马数字Ⅲ）转为标准等价形式。例如：
-
'café'（e 带重音符）→'cafe\u0301'（e + U+0301 组合重音），再经 toLowerCase 后仍可统一比对 -
'１２３'（全角数字）→'123'（ASCII 数字） -
'Ⅱ'（罗马数字二）→'II' -
'ff'（连字 ff）→'ff'
实现文本标准化去重（Set + normalize）
对原始文本数组做归一化后再去重，避免因 Unicode 表示差异导致重复项漏判：
const raw = ['café', 'cafe\u0301', '１２３', '123', 'test'];
const unique = [...new Set(raw.map(s => s.normalize('NFKD').toLowerCase()))];
// → ['café', '123', 'test']
// 注意：'café' 和 'cafe\u0301' normalize + toLowerCase 后都变成 'café'（视觉一致且底层码点也一致）
若需保留原始格式，可用 Map 存储标准化键 → 原始样本代表：
const map = new Map();
raw.forEach(s => {
const key = s.normalize('NFKD').toLowerCase();
if (!map.has(key)) map.set(key, s);
});
const deduped = [...map.values()]; // 保留首次出现的原始形式
增强模糊匹配与搜索容错
在关键词匹配、输入建议或日志归并场景中，先 normalize 再比较，可覆盖更多用户输入变体：
- 用户搜
'coöperate'（带分音符）也能匹配到存储为'cooperate'的条目（normalize('NFKD') 后两者均为'cooperate'） - 搜索
'MATH-Ⅱ'可命中'MATH-II'或'MATH-2'（取决于是否进一步替换罗马数字/数字，NFKD 仅负责第一步转换）
实际匹配建议组合使用：
function normalizeForMatch(str) {
return str
.normalize('NFKD')
.replace(/[\u0300-\u036f]/g, '') // 可选：移除剩余组合标记（如单独的重音符）
.replace(/[^a-z0-9\s]/gi, '') // 可选：只留字母数字空格（按需调整）
.toLowerCase()
.trim();
}
const candidates = ['café', 'naïve', '½ cup'];
const query = 'naive';
candidates.find(s => normalizeForMatch(s) === normalizeForMatch(query)); // → 'naïve'
注意事项与边界情况
NFKD 不是万能的，需结合业务理解谨慎使用：
- 不可逆性：NFKD 可能丢失语义信息（如汉字「後」→「后」，但二者在简繁语境中含义不同），敏感场景（古籍、法律文书）应优先用 NFD/NFC
- 不处理字体/排版差异：如「l」（小写L）和「1」（数字一）即使全角也不互转，需额外规则
- 不解决拼写错误或同音异形：如「颜色」vs「色彩」仍需语义模型，NFKD 只管字符等价
- 性能考虑：高频匹配场景建议预计算并缓存 normalize 结果，避免重复调用
不复杂但容易忽略。真正可靠的文本去重与匹配，往往始于一次恰到好处的 normalize('NFKD')。
