短信发送前的号码状态检测：卡在队列哪一环
一批营销短信发完，回执里的失败号大半是空号，通道费照付。手机号状态查询插在发送链路哪一段最合适、哪几种状态必须拦下、哪些不能拦，这篇按落地顺序拆开讲。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
名单是运营下午导出的两万条，晚上八点开始走通道，第二天早上对账，失败一千八百多条，其中大半是空号。这笔钱按条数已经付过了，通道方还顺带提醒一句：失败率偏高，后面的发信速度会被压。
运营的诉求就一句——别给空号发。技术团队的第一反应是改发送循环：每发一条前先查一次，查到空号就跳过。这个改法撑不过半天，原因不在接口，在节奏。发送器原来每秒能稳定吐几百条，中间插进一个几百毫秒的查询，整条队列就被最慢的一环拖住，通道侧的限额等于白等。
合适的位置在取号排期与真正发送之间，做成一个独立环节。这一批名单先整体送去查状态，拿回结论后切成三个集合——可发、待定、不发，再把集合交给发送器。发送器只认集合，不关心结论是怎么来的。
这样切开的收益有三层。发送侧的速度不再被查询延迟牵制，两边可以各自扩容；查询侧能按批次、按自己的节奏跑，批量提交比逐条查询省得多；名单的排期、去重、重跑逻辑都收在一个地方，出问题只需要看一个环节。
接口返回的是八种状态：正常、空号、通话中、不在网、关机、无短信能力、欠费、长时间关机。落到短信场景，它们不是「能发 / 不能发」两堆，而是三堆。
必须拦的是空号、不在网，以及最容易被忽略的「无短信能力」——这类号码能接电话，收不到短信，做外呼的名单里完全可用，做短信就只能拦下。同一个状态，两套业务两套动作，映射表要按业务分开存放。
不能按空号处理的是关机、通话中。这两个是瞬时状态，过几个小时可能就通了，一旦被剔出名单，等于把这位客户永久放弃了。它们该进待定集合，下一批再排。欠费与长时间关机同样先放待定，跟着复核节奏再处理。
这样分完，真正被移出名单的只剩长期不可达的那部分，名单不会因为一次误判而缩水。
常见的情形是：调度器显示任务在跑，进度条半天不动，最后一查，接口早就返回了，卡住的是把结论写回名单表那一步——逐条更新两万行，比查询本身慢得多。把写入改成批量提交，吞吐的提升往往比调并发更明显。
另外两个数是批量提交的量和查询侧的超时设置。提交量要压在接口的 QPS 上限之内，超时要给重试留出空间；失败与限流要分开计数，否则被限流会被误判成接口不稳定。一次提交多少条、量怎么算，手机号在网状态批量查询：一次多少、量怎么算给过一套算法。这类取舍在名单高峰期的号码状态查询：把限流跑成常态里也按场景拆过一遍。
校验本身按次计费，即买即用，花费的量和拦下的空号数量成正比：名单越脏，前置校验越划算。估算不用重跑整批——把那批历史失败号拿出来回查一遍，看其中有多少落在空号类结论上，再按实际的短信单价与查询单价各乘一遍，账就出来了。
要单独留意的是，校验产生的请求里有一部分压根取不到结论：号段归虚拟运营商、卡是物联网卡、号码在境外，这三类既拦不掉也查不出状态，流程里要单独标记、交给人工兜底，别静默混进统计。
字段与计量口径以【手机号在网状态 API】的商品详情页文档为准，鉴权走请求头携带 AppCode，这一点在自建网关时尤其要收口，别让凭据散落在各业务的配置里。
批次要能重跑。把校验流水和批次号绑在一起，重跑前先看这批号码有没有查过，否则同一批名单会被查两遍，账也翻倍。
结论要带时间戳。发送日志能回溯到「当时查到的是什么状态」，客户投诉过来才有依据。历史结论该怎么处理，号码状态检测结果怎么解读：八种状态对应动作里有分层做法。
状态字典要与业务动作对齐。接口状态到本地动作的映射放在配置里，不写死在代码中，业务规则改了不用发版，也方便两条业务线用两份映射。
校验失败要能降级。查询侧整体不可用时，是整批放行，还是只发标记为正常的号码，得提前定好，别等故障现场再临时拍板。
一批短信的失败号里空号类结论占一成以上，或者这件事每周都要做，前置校验就值得做；反过来，如果只是几百条的触发式通知，号码刚完成过交互，可达性本来就高，查询的花费未必比失败更省。判断的落点始终是量：先把重复与失败来源量化，再决定要不要把这个环节加进链路。
文章评论
发表评论
请先注册/登录后评论