海外手机号检测怎么做？跨国名单的四步处理顺序与字段含义

假设你手上是这样一份表：三万多行，来自表单、展会扫码、旧 CRM 导出和渠道商发来的几个 txt。有的带 +，有的以 00 开头，有的只有本地八位数字，国家列一半是空的，同一个人出现了三次但写法不同。目标是挑出真实可联系、并且在某个社交平台上有活跃账号的那部分。

这类名单不要一上手就丢进平台检测。按下面的顺序走，能少花很多按条计费的钱，也能避免把「格式错」误判成「号码无效」。

先记住这个顺序

1. 格式归一化（统一成 E.164）
2. 归一化之后再去重
3. 按国家/地区分组
4. 基础层检测：线型、在网状态、真实运营商、风险号段
5. 目标平台层检测：是否开通、注册时间、活跃、封禁等
6. 结果按多列落库，再回写 CRM

每一层都在给下一层减量。顺序颠倒的典型后果是：你为一堆固定电话号码付了社交平台检测的费用，而结果全是「未开通」，你还不知道是因为对方没装这个应用，还是因为这个号根本不是手机号。

第一步：统一成 E.164，再去重

ITU-T 的 E.164 建议书规定了全球公共电信网的统一号码结构：国家代码 1–3 位，加上国内有效号码，总长不超过 15 位数字，本身不包含空格、破折号或括号。跨国名单要流转、要送进任何检测接口，先转成这个形态是前提。

实际要改写的通常是这几类：

• 国际冠码写法不一：0086...、+86...、86... 指同一个号，把 00 前缀和分隔符统一掉。
• 保留了国内长途前缀 0：很多国家的国内写法会在区号前加 0，转国际格式时这个 0 要去掉，而不是连着国家码一起拼。
• 缺国家码：只有本地号码段。如果同一行有国家/地区字段或来源渠道能判断，按渠道补；判断不了就单独存成一个待确认分组，不要用名单里出现最多的国家码去猜——猜错的号码会以「无效」身份进入结果，反过来污染你对渠道质量的判断。
• 混进了非号码内容：分机号、备注文字、Excel 把长数字变成科学计数法。

去重放在归一化之后。 归一化前 +44 7700 900123 和 00447700900123 是两行不同文本，归一化后才是同一条。顺序反了，你会为同一个号付两次钱。这一步的详细改写规则可以参考海外号码筛选前怎么做 E.164 归一化。

还要清楚归一化能力的边界：像 Google libphonenumber 这类库的 isValidNumber 校验的是号码是否符合某个国家/地区的号段规划、长度和前缀规则，它不能说明这个号是否真的被运营商分配出去、是否在网、背后有没有真实用户。语法合法只代表「值得继续查」。

第二步：按国家/地区分组

分组不是为了整齐，而是因为后面几层的规则按国家走：

• 各国对手机号段和固定电话号段的划分方式不同，有些市场手机与固话从前缀上就能分开，有些不行；
• 同一个社交平台在不同市场的普及程度差别很大，值得花钱检测的平台不一样；
• 检测项和单价通常按国家/地区与平台分别定价，混在一批里跑，事后很难做成本归因。

实务上按国家码拆成若干子文件，每个国家单独跑、单独看结果分布。哪个市场该优先筛哪个平台，可以先看各国家/地区的号码格式与主流平台对照再决定。

第三步：基础层检测，先把不可能的号去掉

这一层查的是通信网络侧，与任何应用无关，主要拿到三类信息：

线型（Line Type）：区分移动号码、固定电话、VoIP 虚拟号、免费电话等。如果你的目标是移动端的即时通讯类平台，固定电话和一部分非固定 VoIP 号段基本不可能有正常账号，提前剔掉最省钱，也顺带过滤了一批高风险滥用号段。

在网状态：基于运营商 HLR（归属位置寄存器）及实时网络状态查询，判断号码是在网、停机、空号还是欠费断网。名单越旧，这一层的淘汰比例越高。

真实归属运营商：携号转网（MNP）之后，号段前缀显示的运营商和实际归属可能不是一家。如果你要按运营商做分析或计费，只能用查询回来的结果，不能按号段推。

这一层做完，名单通常已经明显变短，剩下的才值得进入平台层。

第四步：平台层账号状态

这是很多人真正想要的一层，也是最容易误解的一层。

通信层和平台层是两个维度，不能互推。 一个在运营商网络里活跃的移动号码，完全可能没注册你要查的那个应用；反过来，一个已经停机的号码，平台上可能还留着历史账号。所以基础层判为「有效」不等于平台层会命中，基础层判为「停机」也不等于平台层一定查不到东西。

平台层能返回哪些字段，各平台不一样。常见的有是否开通、注册时间、活跃情况、是否封禁，部分平台还能拿到性别、年龄等可得属性。差异来自平台自身开放的可见范围，而且会变——某个平台调整账号状态的可见性之后，原来能拿到的字段可能就没有了。所以别把一个平台的字段清单套到另一个平台上，也别把去年的字段列表当成今年的依据。

到了要真的把这份名单跑起来的时候，NexCheck 就是做这件事的：在控制台上传 txt 或 csv，也可以走 REST API 提交，单批不限量，按平台选检测项，结果按有效与无效分组导出，长任务用 Webhook 回推。哪个平台具体能查哪些字段、当前单价多少，以平台页和价目表为准，别照抄任何一篇文章里的字段表。名单是你自己的数据，只在任务范围内处理，来源和用途的合法性需要你自己保证。

结果怎么存：别只留「有效/无效」

很多人导出后只保留一列布尔值，几周后就没法复盘了。至少留这些列：

• 归一化后的 E.164 号码（作为主键）
• 原始写法（用于溯源和排查改写错误）
• 国家/地区
• 线型、在网状态、归属运营商
• 目标平台 + 该平台返回的各字段
• 检测时间、批次号

分开存的好处是无效原因可区分：格式不合规、非移动号段、空号停机、平台未开通、平台封禁，这五种在后续动作上完全不同。格式不合规的可以回头找渠道补；平台未开通的可以换平台再试一轮；空号则可以直接从名单里退役。这套多列落库的思路在批量号码验证别只看有效无效里写得更细。

回写 CRM 有两种做法：一次性名单直接用分组导出的文件按号码匹配更新；持续进单的场景用接口拿结果。

网页端还是 API

判断标准很简单，看这件事是不是要重复做：

• 一次性清理历史名单、或者先试水几个国家：控制台上传更快，不用写代码，跑完下载分组文件。
• 新线索入库即检、或者要定期重跑：走 REST API，提交后用 Webhook 接结果，避免自己写轮询逻辑扛长任务。轮询和回调的取舍见号码检测用轮询还是 webhook 回调好。

几条容易踩的边界

• 检测结果有时效。 在网状态和平台活跃度都会变，同一份名单隔几个月重跑，结果会不一样。什么时候该重跑，取决于名单的年龄和你对误差的容忍度。
• 字段缺失不等于号码无效。 某些国家、某些运营商或某些平台本就不返回某个字段，空值要单独标记，不要归到「无效」里。
• 不要跨平台套结论。 在 A 平台未开通不能推断在 B 平台也没有，这需要分别检测。
• 先小批试跑。 拿 500–1000 条有代表性的样本跑一轮，确认归一化没出错、字段含义和你理解的一致，再把整份名单铺上去。这一步省下来的钱，通常比任何一次性折扣都多。

整份名单处理完，你手上会有一个按国家、按线型、按平台状态切分好的表。它的价值不只是「哪些号能用」，还包括哪个渠道的名单最脏、哪个市场值得换平台——这些判断只有把结果按多列留下来才做得出来。