做 号码数据去重软件，最常见的弯路是：公司已经有一套按邮箱、按客户名合并的工具，于是把手机号当成又一个字段接进去。界面能跑，结果不可信。通用去重解决的是“两行是不是同一条记录”，号码要解决的是“两种写法是不是同一条线路”。
用户侧的对比见 数据去重软件做不了号码这件事。这篇从制作角度写：哪些模块必须自己做，哪些可以借用现成组件。
能借的，和必须自己写的
可以借：
- 文件解析库（xlsx / csv）
- 对象存储、任务队列、权限框架
- 数据库本身
必须自己写，或至少自己维护规则的：
- 号码规范化（国家码、前导 0、本地号长度）
- 比对键的生成与版本
- 文件内去重 + 对库去重的结果模型
- 异常号的归类，而不是直接丢掉
解析库不会告诉你 07700900123 在默认地区是英国时该怎么收。队列也不会替你决定失败重试时要不要把半截结果标成最终。
模块 1：规范化必须产出稳定键
软件内部至少保留三列：
raw：用户文件里的原样region：识别出的或任务指定的地区key：用来 unique 的值，通常是 E.164，例如+8613800138000
查询、索引、历史比对都走 key。页面上给业务看的，仍是原值和可读格式。把原字符串直接 unique，等于没做去重。
键的规则要有版本号。哪天你改了泰国号的长度判断，旧数据不能假装和新规则一致，否则历史重复关系会在没人察觉时算错。库表怎么放这些字段，见 号码数据库系统怎么设计。
模块 2：不要用“模糊匹配姓名”那套
通用号码数据清洗软件喜欢上编辑距离、姓名拼音、公司名相似度。手机号上这么做会出事：差一位可能是真的另一个号，也可能是录入错误。去重层只做精确匹配规范化后的键。
怀疑录错，是质检或人工复核的事，不要在去重软件里自动合并。WhatsApp、短信通道对“差一点的号”也没有容错，误合并会直接打到陌生人。
模块 3：任务和文件解析要跟比对切开
一份 80 万行的 xlsx，光解开、读 sheet、转字符串，就可能比后面的哈希比对更慢。号码数据去重软件要把阶段拆开：
- 接收文件，记录哈希，避免同一文件连点三次变成三个任务
- 解析 + 规范化 + 标异常
- 本文件去重
- 对库去重
- 写结果、给导出
任一步失败应停在该步，而不是整包标记成功。队列和续跑见 手机号码批量去重任务设计。
模块 4：结果不能只覆盖原表
很多从 Excel 插件长出来的软件，习惯“删行后另存”。团队用法不是这样。他们要：
- 留下重复行，用来跟渠道结算
- 知道重复命中的是老客户还是本文件
- 异常行单独给数据组修
所以结果是一份带状态的明细，不是一张更短的表。导出权限还要能禁止普通账号把底库拖走。
模块 5：地区元数据要可更新
国家码、号长、是否保留 trunk prefix，会变。把规则写死在一堆 if country == CN 里，明年就要翻代码。更稳的做法是规则表或元数据包（许多团队会参考 libphonenumber 一类的地区元数据），发布时带版本，出问题能回滚。
全球场景的具体坑——默认地区、00 与 +、前导 0——写在 全球号码去重系统。
制作时一个容易省错的决定
有人用布隆过滤器当“是否在库”的唯一判断，图快。假阳性在号码场景里等于误杀可触达客户。过滤器可以当预筛，最终必须以精确索引为准。要快，先保证键短、索引窄、导入和查询隔离，而不是先上近似结构。速度问题拆解见 号码快速去重软件为什么慢。
给开发排期的建议顺序
不要按页面模块排。按依赖排：
- 规则文档 + 键定义 + 验收样本
- 规范化与单测（各国写法）
- 文件解析和异常标记
- 文件内去重
- 底库与对库比对
- 导出、权限、任务回看
界面可以很朴素。规则错了，界面越漂亮越危险。验收样本怎么准备，见 号码数据去重软件怎么验收。
常见问题
开源表格去重组件能当内核吗？
可以当文件解析和去重算法的参考，不能当号码内核。缺地区规则和键版本，上线后一定返工。
要不要把 CRM 客户合并也做进这套软件？
不要。一人双号、公司总机、家庭共享号，属于客户识别，不是号码去重。硬塞进去，两边规则都会脏。
自己做和直接用现成系统怎么选？
若核心就是名单进、状态出、库自建，优先看现成能力，不必从解析库重写。演示：在线 Demo。部署咨询：Telegram @imchat。架构说明在 底层架构。