手机号去重实战:忽略格式差异把同一个号码合并成一条

做营销名单和 CRM 维护的人都遇过一种尴尬:同一个客户的手机号在系统里存了两遍,一遍是 +86 138 0013 8000,另一遍是 13800138000。肉眼看是一个人,数据库里是两条记录。结果群发短信时这个人收到两条一模一样的内容,投诉就来了。

问题的根子不在去重逻辑,而在比较之前没有把号码"对齐"。下面讲清楚为什么会这样,以及怎么用一套稳妥的顺序把它处理干净。

为什么同一个号码会被当成两个

字符串相等比较是按字面一个字符一个字符比的。下面这几种写法在人看来是同一个号码,在程序看来却各不相同:

• 13800138000
• +86 138 0013 8000
• 138-0013-8000
• 0086-13800138000
• 138 0013 8000(中间带空格)

区别全在格式符号上:加号、国家码 86、空格、横线、前导 00。只要这些干扰还在,任何直接比相等的去重都会漏掉,因为它们的字面值确实不一样。

正确的顺序:先归一化,再比较

要让去重生效,必须在比较之前做一步归一化,也就是把所有号码统一成同一种形态再去比。一个对国内手机号稳妥的归一化规则是这样:

1. 去掉所有非数字字符,空格、横线、括号、加号全部删掉。
2. 处理国家码:开头是 0086 的去掉 00,开头是 86 且后面正好跟 11 位的去掉 86,得到纯 11 位本机号。
3. 对剩下的数字做长度和号段校验,确认是合法的 11 位手机号。

走完这三步,前面五种写法都会收敛成同一个字符串 13800138000,这时候比相等才有意义,重复的自然就并到一起了。归一化这步可以单独用电话号码归一化工具先跑一遍,确认规则符合你名单的实际情况,再整体去重。

一个真实的输入输出例子

把下面这段贴进电话号码去重工具:

+86 138 0013 8000
13800138000
138-0013-8000
13912345678

去重之后的输出是:

13800138000   (出现 3 次,首次在第 1 行)
13912345678   (出现 1 次,首次在第 4 行)

四行进去,两行出来。前三行尽管格式各不相同,归一化后都是同一个号码,被合并成一条,并且保留了"出现 3 次"和首次行号这两个证据。这两个信息很关键:交接名单时别人会问重复是从哪来的,有行号就能回到原始数据核对。

我自己清名单时的习惯

我维护过一份从三个渠道导出的活动名单,合并之后大概一万两千行。第一遍我直接做了字面去重,以为干净了,结果群发测试时还是有人收到两条。回头一看,正是 +86 前缀和带空格的写法漏过去了。后来我固定改成两步走:先归一化拉齐格式,再去重。同样这份名单,实际去掉的重复比第一遍多了快两百条。从那以后我再没跳过归一化这步。

无效项要单独留着,不要硬合

去重时会碰到长度不对的号码,比如 138 0013 800 少了一位。这种号码没法跟完整号码安全比对:它可能是任何一个 1380013800X。稳妥的做法是把它带着原因单独留出来复核,而不是硬塞到某个相近号码下面。否则它要么被错误合并,要么从去重计数里悄悄消失,两种都是坑。把无效项保留出来,你才能人工决定是补全还是丢弃。

名单永远不要外发去比对

这是营销和运营数据最该守的一条线:客户手机号属于敏感个人信息,把整份名单上传到某个在线服务去做去重,本身就是一次数据外泄风险。上面这套流程从解析、归一化、比较到导出全部在浏览器当前标签页里完成,名单不离开你的设备。你可以放心把两份 CRM 导出叠在一起找重叠,数据不会被发出去做比对。

清洗完成后,可以直接导出 CSV 交给 CRM 或工单系统,也可以导出带行号的 Markdown 留作审计线索。比起只复制最终列表,带行号的产物在出问题时能帮你快速定位到原始那一行。

把"先归一化再去重"这个顺序固定下来,同一个号码不管写成 +86、带空格还是带横线,都会乖乖合并成一条,重复短信和重复记录的问题也就从源头堵住了。

---

Made by Toolora · Updated 2026-06-13