公司用了很长时间的电话号码，最让人头疼的，不是这些电话号码有没有问题，而是号码已经变了。

一年前在 CRM系统中输入的用户号码，现在看起来依然是11位数字，但现实中的情况却不一样了：有些人的号码已经停机了，有些人变成了空号，有些人甚至很久都没有用过。如果只是看格式的话，基本上是看不出来的。

在我们探数 API官网里，有一款接口名为“手机状态查询”的API可以检测到手机号的状态。输入手机号码后，可以看到这个号码当前的状态分类，包括0空号 1实号(活跃) 2停机 3库无 4沉默(不常用) 5风险号，还可以显示出各个省份、城市、运营商等相关信息。

这样的查询更适合于历史客户的整理，号码的清理，市场名单的筛选之前。要弄清楚自己的号码，才能确定下一步该怎么使用。

一堆旧号码，有什么好调查的？

在收集电话号码之前，必须要进行格式验证。数字错了，输入错了，这是一开始就该解决的问题。但是，如果是在系统里放了半年或者一年的话，那就不同了。

例如，某家公司想要将一组去年遗留下来的电话号码重新激活，而资料库中的电话号码看似一切正常，却并不意味着这些电话号码就会一直保持原样。所以，现在再次确认“是不是11位”，对他的帮助并不大。而空号检测，则是针对后一层。同样一批格式正常的手机号，那就会有不同的结果。

从号码清洗的角度看，这种分类比单纯判断“空号还是实号”更方便。停机、沉默和风险本来就不是同一种状态，完全没有必要把所有的“无效号码”都整合到一起，然后再进行一次数据处理。

沉默号和风险号，保持原状是最好的

这两个状态比较容易被误解。
我们的API设定：“沉默号”是指半年以上没有使用过的空号，在过去3个月内，平均流量在30 M以下的用户。

所以status = 4 返回的是沉默号，不应该直接改成空号。
企业当前如果暂时不使用这一类号码，可以在自己的业务规则里处理，但原始查询结果最好保留下来。以后策略变了，还能知道当时查到的到底是什么状态。

风险号也是如此。
设定为：风险号涉及长时间关机、未开通语音服务以及易投诉用户。
⚠️ status = 5 表示的是接口定义中的“风险号”，不能继续推断为诈骗号码、欺诈号码或违法号码。
如果有更多的风险控制要求，那就得综合其他的数据，以及公司的内部规则来确定。

🗂️号码状态不是查一次就永远不变

这一点对长期号码库比较重要。
原来停机的号码可能重新恢复使用，空号后续也可能重新投入使用。因此，同一个号码在不同时间查询，结果不一定一直相同。

如果系统需要长期保存检测结果，除了接口返回的 status，最好把本次查询时间一起记下来。
例如一条号码记录可以保存成：

“查询时间”不是接口返回字段，而是企业自己增加的数据。
这样几个月后再看到一条 status = 1，至少可以先确认这是刚查出来的，还是很久以前的旧结果。

📞 应用场景

企业真正需要做空号检测的地方，往往不是刚刚收集的新号码，而是已经积累了一段时间的旧数据。
比如活动报名留下来的手机号、几年没有联系的客户、会员系统里的旧联系方式、售后系统积累的联系电话，或者从不同系统合并过来的号码库。
这些数据重新启用之前，可以先做一次手机号状态查询。
营销名单也是一样。先把不同号码状态区分出来，后面怎么处理，再交给业务规则。
这里还要把两个问题分开：
实号，只代表当前接口返回的是实号。
它并不表示企业自动取得了向该号码发送营销短信或拨打营销电话的授权。号码状态查询解决的是数据问题，后续通信行为仍要按照实际适用的授权、隐私和通信规则执行。

接口实际返回什么？

当前接口的核心返回字段有：
字段类型说明phonestring手机号provincestring省份citystring城市ispstring手机号运营商statusstring号码状态
其中号码分类主要看 status。
当前资料提供的 JSON 返回示例：

{
  "code": 1,
  "msg": "操作成功",
  "data": {
    "phone": "15878458784",
    "province": "广西",
    "city": "梧州",
    "isp": "移动",
    "areacode": "0774",
    "zipcode": "543000",
    "status": "1"
  }
}

这里的：

"status": "1"

对应实号（活跃）。

手机状态查询 API 接入信息

接口地址：

https://www.tanshuapi.com/market/detail-72

返回格式： JSON
请求方式： 不限
请求参数：
参数必填类型说明key是stringAPI 密钥，个人中心查看phone是string手机号
请求示例：

https://api.tanshuapi.com/api/phone_invalid/v1/index?key=YOUR_API_KEY&phone=XXXX

正式接入时，真实 API Key 不建议直接写在公开网页、公开代码仓库或者可以被用户查看的前端代码里。
接入系统以后，建议数据库保留接口原始 status，不要在查询层直接把沉默号改成“无效”，或者把风险号改成“禁用”。
查询层只保存原始结果，后续怎么处理交给业务层。这样以后规则变化时，不需要重新修改接口逻辑。

手机状态查询和在网状态查询不是同一个产品

探数 API 官网里的手机状态查询对应运营商空号检测，当前返回空号、实号、停机、库无、沉默号和风险号。

官网同时还有独立的运营商在网状态查询产品，关注的是号码在网状态。
两类接口名字比较接近，但并不是同一个产品。

如果业务主要是清理历史号码、做空号检测或号码状态分类，对应的是手机状态查询；如果需要其他在网状态信息，则应选择相应的在网状态产品。

接口报错时可以先这样排查

服务级错误码：
错误码说明207201缺少必要参数207202查询失败
系统级错误码：
错误码说明10001错误的请求 KEY10002该 KEY 无请求权限10003KEY 过期10004未知的请求源10005被禁止的 IP10006被禁止的 KEY10007请求超过次数限制10008接口维护
如果返回 207201，先检查参数是否完整；如果是 10001、10002、10003，重点检查 KEY 和权限。10007 对应请求次数限制，10008 则表示接口维护。
这样分开看，比统一把错误处理成“查询失败”更容易找到原因。

写在最后

命中准确率100%，误差率5%
号码清洗做到最后，其实还是回到一个很普通的问题：这批手机号虽然都还在系统里，但现在是不是还处于原来的状态。
对刚录入的数据，格式校验已经能解决不少问题；对保存了一两年的历史数据，只看号码格式就不够了。
手机状态查询把空号、实号、停机、沉默号等状态补充回来，企业再按照自己的业务规则做后续分类和维护。对于 CRM、历史客户名单和长期号码库来说，这比单纯检查手机号位数更有实际意义。
心动不如行动→手机状态查询API（点击可跳转）