手机号查询开通状态：在网状态接口怎么对应
接口不返回开通或未开通，而是八种在网状态。这篇问答讲清手机号在网状态的判定口径、为什么两套系统显示不一样、二值怎么映射、哪些状态能当决策依据，以及查不到状态的号码怎么归。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
先把答案给出来：手机号查询开通状态这类接口，返回的不是「开通」或「未开通」两个取值，而是八种具体状态——正常在网、空号、不在网、通话中、关机、欠费、无短信能力、长时间关机。所谓开通状态，是业务侧把这八种状态压成两种取值之后的通俗说法，压的过程里丢掉了一批本来能直接落地的动作信息。下面几个问题是接入之后最常被反复问到的。
云市场上的号码状态类接口，返回的是号码此刻的可达情况，不是一个布尔开关。正常在网意味着马上能联系上；通话中与关机意味着暂时联系不上，过一会儿可能就通了；空号与不在网是号码本身已经不用了；欠费介于两者之间，要看业务怎么判断；无短信能力这一档比较特殊，号码能接通，但短信通道走不通。
所以当业务方问「这个号开通了吗」，技术侧值得先反问一句：你判断的是能不能打电话，还是能不能发短信。两个用途的结论不一样。
最常见的原因是查的时点不同。通话中、关机属于瞬时状态，两套系统在不同时间查，结果自然不同，两边都没有报错。另一个原因是两边压成二值时的规则不同：一边把通话中也算可触达，另一边只认正常在网。
还有一种情况是缓存。一方把结果缓存了几个小时甚至几天，另一方现查现用，两边就会长期对不上。排查这类分歧时，先对一下查询时间戳和缓存时长，多数分歧在这一步就能解释完，不必上升到数据质量问题。
可以压，但建议留一层。数据库里原样保存接口返回的状态，另外加一个派生字段表示二值判断，映射规则写在配置里而不是写死在代码分支里。
映射规则还要按用途分开定：做外呼的团队，通话中和关机可以算可触达；做短信通知的团队，无短信能力必须算不可触达。同一份查询结果服务两个用途，二值口径就不该只有一套。空号检测接口常见问题：鉴权、并发与错误码里讲过结果落库时的字段取舍，映射表别写进业务逻辑这一条同样适用。
稳的那几类可以直接用：空号、不在网在一段时间内基本不会翻回来，作为剔除依据是安全的；正常在网可以直接进入触达队列。
需要谨慎的是瞬时状态。通话中、关机、长时间关机会变，拿它们做剔除，等于把一个临时状态当成长期结论，名单上会多出许多本该保留的号码。
处理办法是给瞬时状态设一个复核窗口：隔一段时间再查一次，连续两次落在同一类结果上，才进入降级或剔除处理。代价是多一次调用，按次计费下这笔钱可以按比例估出来。
会变，而且比预期快。停机、补卡、转网、销户都会改变状态，其中一部分变化在几小时内就能被接口看到。
刷新节奏取决于用途。面向当日触达的名单，结果当天用完就够，跨天使用就要重查；面向客户档案这类长期字段，可以按周或按月复核，再密的节奏收益也很小。
别把刷新频率设得太高。同一个号码一天查好几次，除了抬高调用量，对判断没有什么帮助，因为状态发生变化的概率远低于查询次数。
接口结果适合内部做判断，不适合当成对外出具的证明。它对外能说明的只有一件事：某个时间点上，这个号码处在某个状态。它既不构成号码归属的证明，也不构成机主身份的证明。
业务上确实需要对外出具的场景，要先确认用途与授权范围，结果里也不要附带与用途无关的信息。这一块出问题往往不在技术实现，而在用途表述太宽。
三类：号码归属虚拟运营商号段、属于物联网卡，或者是境外号码，这几种情形下接口不会给出状态。业务侧最好提前约定这类号码怎么处理——进人工队列，还是在二值口径里保留一个未知取值。
省事的做法是让二值字段允许三个取值：可触达、不可触达、未知。为了报表好看把未知强行并进不可触达，后面一定会有人拿这批号码去追问为什么联系不上。
如果打算把这套映射直接落在系统里，可以从【手机号在网状态 API】起步：直连三网，支持携号转网识别，返回的状态正好对应上面这些动作分层，鉴权走请求头携带 AppCode，按次计费、即买即用，字段定义以商品详情页文档为准。落库与映射该放在哪一层，订单系统接入号码状态查询：一次批量任务的重构里有个可参考的分层，映射表放配置文件这一条尤其值得照做。
文章评论
发表评论
请先注册/登录后评论