在一个公司的系统中，最容易被忽视的不是一个错误的电话号码，而是一个没有任何问题的号码，但却被人用掉了
如果一个人的手机号码被注销了，那么这个号码就会被运营商收回。手机号本身并没有改变，但是其与原有账号、会员、客户信息的关联，却有了很大的改变
在长期的客户关系管理，会员系统，帐户系统的维护中，这样的问题屡见不鲜。尤其是在重新登陆旧号、找回手机号、重访客户的时候，光看“这个号能不能接收到短信”是远远不够的，毕竟能接收到信息，只代表着有人在用，而不是真正的用户
探数 API 的全网手机二次放号查询API，就是针对这类号码关系变化提供查询能力。传入手机号后，可以返回是否属于二次放号、当前运营商、是否携号转网、号码原所属运营商等信息
📌总而言之
二次放号查询不是判断“手机号有没有效”，而是帮助平台判断：这个号码有没有经历过重新放号

为什么现在越来越多平台开始关注二次号码？

过去，平台更关注的是号码是否可以使用，验证码是否可以接收；随着账号系统的不断完善，手机号被用来登录、找回、通知，甚至是身份绑定，号码重新放号之后，如果不能及时解决，很容易出问题
2026 年工信部公布的“二次号码焕新”服务数据里，已经覆盖258 款常用互联网应用，累计服务用户超过1435 万人次，申请解绑应用超过8.5 亿次
能说明一个现实问题：
➡️二次号码，不再是一种很少见的边缘状况，这是一种在管理账号时必须要考虑的问题
《检察日报》2026 年 7 月的相关报道中，也提到了二次号码可能带来的旧账号绑定、注册受阻、历史信息残留等情况
对企业来说，真正需要处理的并不是“号码为什么被重新放出来”，而是：
系统里原本的电话号码，还能用吗？

哪些 B 端业务最值得查二次放号？

✅ 老账号重新登录或找回

这一类场景最典型。
一位超过一年未登入的使用者，忽然以原来的电话号码要求取回该帐号。如果是在这段时间里，这个号码已经出现了第二次，那么“可以接收到验证码”的情况，并不足以证明当前操作者就是原账号持有人
这时可以把二次放号状态作为一项补充判断：
老账号重新登录 / 找回 → 查询手机号是否二次放号 → 再结合账号绑定时间、历史资料或其他验证方式处理
这里一定要注意：
二次放号 ≠ 原账号一定换人
比如某个号码早在用户注册这个平台之前就已经发生过二次放号，那么当前查询到“二次放号”，并不能说明这个平台里的账号关系存在异常
所以说，这界面更多的是一种辅助判定，而不是单纯地判定一个账号的归属

✅ 新手机号注册或重新绑定

在新用户登记时，若已发生二次放号，则平台可依据自身业务风险需求，自行添加其它确认措施。
但这类结果不能直接写成：
“二次放号 = 高风险用户”
这不成立。
这个界面只会询问一个人的历史记录，而不会去判断这个人有没有说谎。在登记、交易、账户安全等方面，二次放号在风险控制中的作用较大，更多地作为风险控制的依据，而非最后的结果。

✅ CRM 和历史客户号码整理

CRM 里很多号码可能已经保存两三年。
号码格式没变，甚至现在还能正常使用，但和最初客户之间的关系可能已经变化。
如果企业准备重新启用一批历史客户数据，可以先查询二次放号状态，再决定是否需要重新确认联系方式。
在这种情况下，二次放号查询并不能解决“数字的有效性性”问题，它只会让用户之间的关系变得更有价值。

二次放号查询API会返回哪些信息？

当前接口返回的核心字段不多，重点比较明确：
| phone | 手机号码 
| status | 1 二次放号；2 非二次放号 
| isp | 当前运营商：1 移动、2 联通、3 电信 
| is_xhzw | 是否携号转网：1 是、0 否 
| isp_real | 号码原所属运营商：1 移动、2 联通、3 电信 
其中真正判断“有没有二次放号”的字段是：

status

对应关系：

1 → 二次放号
2 → 非二次放号

开发接入时建议把接口原始值保存下来，不要直接改成“安全”“风险”“有效”“无效”这类业务标签。
因为这些标签属于企业自己的判断，不是接口原始定义。

二次放号和携号转网，别混在一起

这两个状态经常同时出现，但概念完全不同。
二次放号指号码被回收后重新投放给其他用户。
携号转网则是号码不变，但用户把运营商从一家转到另一家。
所以接口才会分别返回：

• status：是否二次放号
• is_xhzw：是否携号转网
• isp_real：号码原所属运营商
  📌 举个简单的理解方式：
  一个号码可以发生携号转网，但并没有发生二次放号；也可以发生过二次放号，但当前并没有携号转网。
  两个字段不要混着解释。
  

  API 怎么调用？

  接口地址：

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

  返回格式： JSON
  请求方式： 为“不限”

  请求参数

  参数必填类型说明key是stringAPI 密钥，个人中心查看phone是string手机号码date否string检测日期，格式 yyyyMMdd，默认当前日期
  这里对 date 只保留当前产品资料已经确认的定义。
  目前资料没有进一步说明它对应的业务时间口径，因此不把它解释成“查询某日是否二次放号”或“判断某日起是否发生二次放号”。

  JSON 返回示例

  {
  "code": 1,
  "msg": "操作成功",
  "data": {
    "phone": "",
    "status": "2",
    "isp": "2",
    "is_xhzw": "0",
    "isp_real": "2"
  }
  }
  

  这条结果里：
  ✅ code = 1：接口请求成功
  ✅ status = 2：非二次放号
  ✅ is_xhzw = 0：未携号转网
  ✅ isp = 2：联通
  ✅ isp_real = 2：原所属运营商为联通
  这里有一个开发时很容易写错的地方：
  code = 1 只代表请求成功，不代表号码一定是“非二次放号”。
  真正判断二次放号，要看：

  data.status
  

  同样，查询失败也不能默认按“非二次放号”处理。
  

  查询失败时，先看错误码

  服务级错误码：
  错误码说明213001缺少必要参数213002查询失败
  系统级错误码还包括：
  错误码说明10001错误的请求 KEY10002该 KEY 无请求权限10003KEY 过期10004未知的请求源10005被禁止的 IP10006被禁止的 KEY10007请求超过次数限制10008接口维护
  如果业务系统要自动处理结果，建议至少区分：
  ➡️ 请求成功 + 二次放号
  ➡️ 请求成功 + 非二次放号
  ➡️ 查询失败
  不要把“查询失败”直接归进“非二次放号”。

这类 API 真正解决的不是“号码有没有效”

二次放号查询更关注的是手机号背后的历史关系。
一个号码现在可以正常接收短信，不代表它一直由同一个人使用；反过来，查询到二次放号，也不能直接证明当前账号关系有问题。
对于平台来说，更合理的用法是：
二次放号状态 + 账号绑定时间 + 历史资料 + 其他验证方式 → 再决定业务处理
这样二次放号查询才真正进入账号安全、客户资料维护和历史号码清洗流程，而不是变成一个单独的“是 / 否”标签。