为什么需要 canonical 字面

作为去重的稳定键，避免不同来源的字面差异造成重复入库。

能否只做大小写归一

不够；分隔符与全半角差异同样会产生重复记录。

从变更日志里恢复原始记录到主表，并标记回退原因。

不会；建议在字段模型里单独保存原始字面列。

直接答案：结论先给：番号库的编目思路与规范化以公开命名与检索方法为准，下文按定义、结构、判定三步展开。

在番号库编目里，来源不一的字面差异会让相同条目被误判为不同记录。本文列出四步规范化流程，配合持久化番号库定义与元数据字段速览，给出去重与合并的判定规则。示例数据供参考不代表真实统计。同族里可先看库层归一化入库切结构骨架与库层归一化入库切主词定义脉络互为参照, 跨族则以番号大全的分类维度设计与番号核验流程与工作单做外部锚点。

本文只涉及公开字面的规范化处理，不讨论条目内容访问路径；示例编号取自模拟数据。

四步顺序执行，每一步都记录中间态便于回溯：大小写归一化、全半角合并、分隔符替换、相同 canonical 去重。以下用一个具体示例演示，把 Mide-234a 变成 MIDE-234A 再落库。

归一清洗与社区讨论边界的裁剪有对读：社区讨论边界对归一清洗的裁剪对读给出社区讨论边界对归一清洗的裁剪对读。

目录归一在社区回帖场景里也要做同样清洗：番号吧元数据要点给出社区回帖走向归一化清洗的做法。

规范化产出的 canonical 字面是去重的依据。若两条记录的 canonical 相同，进入合并候选池；再比对编号结构分段与来源时间戳，取较早者为主记录，较晚者存入变更日志。canonical 相同 → 候选时间戳较早 → 主记录

候选并非一定合并。若两条来源的元数据存在冲突，例如发行方或命名族不一致，需要保留争议标记等待人工核验，详见条目核验流程。

冲突分三级：字段可空的忽略取补集；字段可枚举的取多数派；字段自由文本的走争议标记。以示例三万条样本估算，可自动合并的比例约 87%，其余走人工。

陷阱一：把后缀字母误当成数字段末位。陷阱二：忽略零填充差异，让 MIDE-034 与 MIDE-34 变成两条番号记录。陷阱三：对分隔符做过度替换，让 N-1 里的连字符被替换成空格，破坏原番号字面。避免这些需要在流程头部固定番号命名族语义。

规范化后的记录更利于跨源合并与聚合统计。以示例三万条样本估算，规范化让去重后条目下降约 4.6%，让按命名族聚合的统计误差从 3.1% 降到 0.8%。规范化不改变原始字面，只在 canonical 列上落地。

建议保留原始字面并单独存一个数值化列，便于按数字排序而不丢失原样。

按发行方文档固化规则，例如统一去掉后缀前的分隔符，或统一替换为固定符号。

保存在变更日志表里，便于回溯与审计；主表只保留合并后的规范记录。

本文只覆盖字面层规范化，不涉及跨编号系统的映射与语义等价判定。分类边界尚在讨论，示例数据供参考不代表真实统计。

相关阅读：入库前的命名族识别检查，可对照本节内容进一步展开。

相关阅读：分隔符解析归一化步骤，可对照本节内容进一步展开。

相关阅读：库工作流中的归一化环节，可对照本节内容进一步展开。