String.prototype.normalize() 无法实现多音字或常用异体字的语义等价匹配，仅支持 Unicode 定义的标准/兼容等价转换，如全角转半角、带圈数字归一化等；“峰/峯”等因属独立码位且无等价声明，需配合自定义映射表实现业务层归一。
String.prototype.normalize() 本身不能直接实现多音字或异体字的“语义等价匹配”，它只处理 Unicode 层面的**标准化形式转换**（如 NFC/NFD/NFKC/NFKD），对汉字读音、字义、方言变体或人工约定的异体关系（如“峰/峯”“够/夠”“为/為”）不具识别能力。真正能用于原始字符等价匹配的，是它配合 Unicode 标准中已明确定义的**兼容等价（compatibility equivalence）和标准等价（canonical equivalence）规则**——而这些规则仅覆盖极小一部分汉字变体（主要是历史兼容字符、全角/半角、上下标、带修饰符的拉丁字母等），**不包括绝大多数中文多音字或常用异体字**。
哪些汉字变体可通过 normalize() 实现等价匹配？
仅限 Unicode 标准中被明确标记为“兼容等价”或“标准等价”的字符对。常见可标准化的类型有：
-
全角 ASCII 字符 → 半角：如全角数字“１２３”经
.normalize('NFKC')变为 “123” - 带竖线/圆圈的拉丁字母 → 基础字母：如“①②③” → “123”，“ＡＢＣ” → “ABC”
- 部分日文平假名/片假名的旧字体与新字体（极少数）：如“㋐”（平假名循环符号）在 NFKC 下可能归一化为“あ”（但非普遍）
- 带组合附加符号的字符（极少用于汉字）：如“汉”本身无组合符，但若人为构造“漢̃”（加波浪符），NFD 可将其拆分为“漢 + ̃”，再用 NFC 合并——但这不是真实异体字场景
为什么“峰/峯”“够/夠”“为/為”无法靠 normalize() 自动等价？
这些属于 Unicode 中的独立码位（distinct code points），彼此既无标准等价关系，也未被定义为兼容等价对。例如：
- “峰” U+5CF0，“峯” U+5CED —— 两个完全不同的汉字码位，Unicode 未声明二者可互换
- “够” U+591F，“夠” U+8CB3 —— 简繁体对应，但 Unicode 视为不同字，normalize() 不做映射
- “为” U+4E3A（简体），“為” U+70BA（繁体）—— 同样无标准化关联
它们的等价性来自语言习惯、地区规范或人工词表，而非 Unicode 编码层规则。因此 "峰".normalize() === "峯".normalize() 恒为 false。
实用替代方案：结合 normalize() 与自定义映射
若需支持异体字匹配，应将 normalize() 作为预处理步骤（清理全角、符号等干扰），再叠加业务层映射：
-
步骤 1：统一格式干扰：先用
NFKC转换全角标点、数字、空格等，避免“ＡＢＣ．”与“ABC.”因格式差异不匹配 -
步骤 2：构建异体字映射表：按需维护 JSON 或 Map，例如：
{ "峯": "峰", "夠": "够", "為": "为", "裏": "里", "鍾": "钟" } -
步骤 3：标准化 + 映射归一化：对输入字符串逐字查表替换，再比较
function normalizeChinese(str) {<br> return str.normalize('NFKC').replace(/./g, c => mapping[c] || c);<br>}
多音字匹配需完全脱离 normalize()，依赖语义层
“长”读 cháng 或 zhǎng、“行”读 xíng 或 háng，属于同形异音字（homograph），其读音由上下文决定。normalize() 无法感知语境，也无法生成拼音。可行路径是：
- 接入中文分词 + 词性标注工具（如结巴分词、LAC、HanLP），识别“行长”中的“行”为名词，倾向 háng 音
- 使用拼音库（如 pinyin、pinyin-pro）获取多音字所有读音，构建音近索引（如模糊搜索时展开“zhǎng”和“cháng”）
- 对搜索场景，可预建“字→音→义→同音字”倒排表，而非依赖字符层面归一
