业务侧已经写过为什么要 自建号码数据库，以及空库怎么 落到日常比对。这篇对着做系统的人：一套 自建号码数据库系统 从需求到上线，步骤顺序错了，后面全是补丁。
“自建”不是自己买一台机器这么简单。它指规则、底库、账号和导出都在你控制的环境里。云主机还是机房，是部署选项；规则和数据归属才是系统目标。
第 0 步：先出三页纸，再开仓库
很多项目第一天就建表。建议先逼业务在纸上签字的只有三件事：
- 什么叫重复（含国际号写法、分机、虚拟号）
- 哪些历史数据必须进底库，哪些只进“观察”不要当重复依据
- 谁可以导出通过号、谁可以导出整库
这三页不定，开发做的每一张表都会返工。功能边界可对照 手机号码去重工具开发功能清单。
第 1 步：键和规则版本一起设计
系统核心不是“号码列表页”，是比对键。
- 库里 unique 的是规范化键，不是表格原文字符串
- 每条记录保留 raw、region、key、source、imported_at
- 规则打版本。例如
rule_v3。改号长判断时，旧任务结果仍能解释当时为什么判重复
没有版本的规则，三个月后没人说得清“这批为什么和那批口径不同”。表怎么拆，见 号码数据库系统怎么设计。
第 2 步：底库分层导入，禁止第一天倒全部 Excel
制作流程里这一步最容易被项目经理跳过。把五年间所有采购包一次性灌进去，库会充满：
- 被 Excel 科学计数法破坏的号
- 未标地区的国际号
- 测试号、员工号、重复采购的同一包
建议只先导入两层：成交/投诉等“必须保护”的号，以及近两个季度的获客包。其余分批，带着来源标记进。乱数据进了 unique 索引，以后只能靠人工挖。
导入任务要可回滚：一批发现地区设错，应能按 batch_id 撤，而不是手改几万行。
第 3 步：权限和审计跟功能同一迭代，不要“上线后再加”
自建的意义之一是名单不外传。如果第一版所有人都能把底库下载成 xlsx，系统只是换了个存放位置。
最小角色：
- 管理员：规则、账号、整库导出
- 运营：创建任务、看结果、导出当次通过/重复
- 业务：提交查重，看不到底库
每次导入和导出记操作人、文件名、条数。误伤时才有东西可查。多人同时用时的队列问题，见 号码去重复软件如何支持多人查重。
第 4 步：试运行用“脏样本”，不要用演示用的干净号
上线前至少跑一周并行：旧流程继续，新系统出结果，人工抽查不一致的行。样本里必须有：
- 混写国家码
- 前导 0 的国外本地号
- 确定重复的探针号
- 被 Excel 改坏的单元格
- 空表头、多 sheet 的 xlsx
只拿 20 个国内 11 位干净号验收，上线当天就会被真实文件打脸。验收清单可以复用 号码数据去重软件怎么验收。
第 5 步：把系统嵌进已有工序，而不是多一个后台
系统如果只是“登录看一看”，两周后没人用。要规定：
新名单 → 系统出通过号 → 通过号才能进外呼/短信/社交 → 触达结果按需回写（接通、成交、投诉）
回写不是第一版必做，但表上要留状态位。做到这一步，库才开始值钱。产品侧对应的导入、全球格式和权限，见 核心功能；部署形态见 底层架构。
制作流程上三个特别容易翻车的点
中途改默认地区。 一批东南亚号按中国规则收，键全错。默认地区必须是任务级参数，不要写成全局常量后偷偷改。
用生产库当测试库。 开发用真实客户号调试导出，等于又开了一条泄漏通道。测试库用脱敏号。
没有失败续跑。 80 万行在 60 万处进程被杀，重跑却从 0 开始并且重复写入。任务要按分片或游标可续，状态机见 手机号码批量去重。
常见问题
自建号码数据库系统一定要自己写代码吗？
不一定。关键是数据和规则在你这边。可以用现成系统部署到自己环境，不必从解析库重写。自己写的成本主要在规则维护和各国格式，不在页面。
第一版要不要上分布式？
库在百万级以内，先把规则、任务、权限做对。分布式是规模上来之后的事，见 亿级号码怎么做到秒级去重。过早分片会让规则版本和批次回滚更难。
从哪看一套已按这个流程搭好的系统？
在线 Demo 看任务和结果形态。按自己底库部署，联系 Telegram @imchat。