号码状态查询的移动端直连：密钥放哪
注册页想让用户输完手机号就提示空号，前端同学打算在小程序里直接调号码状态查询接口。AppCode 放进客户端等于公开，这篇讲代理层该放在哪、返回结果怎么裁、防刷与延迟怎么权衡。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
上线前一周，产品提了个需求：注册页用户输完手机号，立刻提示这个号是空号，省得人家填完全套资料才被驳回。前端同学看了一眼接口文档，说就一个地址加一个请求头，他在小程序里写完不到两百行，连自家后端的往返都省了。
评审会上有人问了一句：AppCode 放哪。会议室安静了几秒。
移动端没有秘密。打包进去的字符串会被反编译出来，抓包工具能看到请求头里的每一个字段，崩溃日志偶尔还会把配置整段带出去。加壳、混淆只能抬高门槛，抬不到安全。
问题不在于谁会盯上你的小程序，而在于泄露之后你控制不了损失。鉴权信息一旦落到别人手里，任何一台机器都能拿它查号，请求头长得和你发的一模一样。服务方看到的是你的账号在按次扣费，量冲上去限流也是限你；账单和配额都在你这边，收益在别人那边。
HTTPS 解决不了这件事。它保护传输过程，包里那串字符还是明文躺着。
只有一条业务线、调用量不大，把查询放在自家后端的一个内部接口后面，是最省事的位置。多一跳，但鉴权、限流、留痕、字段裁剪全在自己手里，出问题改一行配置就能停。
业务线多、已有统一网关的团队，把查询挂到网关上更顺。凭据只存网关一处，各业务系统声明要查哪批号码，配额按业务线在网关上切。代价是网关成了新的单点，它的超时设置会直接变成业务侧的超时。号码状态查询的超时与连接：六个问题排过这个取值顺序。
边缘函数适合地缘分散、延迟敏感的场景：客户端就近打到节点，节点再出网。要确认两件事——运行环境能不能出网，凭据在边缘侧怎么托管。托管方式没搞清，只是把包里放密钥换成了配置里放密钥。
接口给的是八种状态：正常、空号、通话中、不在网、关机、无短信能力、欠费、长时间关机。这套枚举适合后端判断，直接丢给前端会被误用。有团队把通话中和不在网都当成不能用，注册页把一个马上能接通的用户拦在门外。
代理层该做的是裁剪：把结论压成三档，可触达、暂不可达、空号，各附一个建议动作。文案再按场景写：空号提示换号，关机提示稍后再试，其余放行。字段留得越少，前端越不容易自己发明语义，号码状态查询的请求字段：那张表该裁到几列画的就是这条线。
返回里也别带号段归属、运营商这类附加信息。注册页用不上，泄露了倒是给撞库的人省了事。
凭据不出客户端之后，客户端仍然可以无限次调你的代理接口，这里是新的敞口。
第一件事是双维度限流：按设备、按账号各算一条线，取小的那个。只按 IP 限，同一栋楼的共用出口能把整栋楼挡掉；只按账号限，注册前的匿名请求压根没有账号。
第二件事是挡重复。同一个号码在十分钟内被查第二次，直接返回上一次结论，不再发往服务方。做活动时这一步能省掉两三成的调用量，号码状态查询省量：缓存与去重的维护账算过这笔账的边界在哪。
第三件事是不给探测留反馈。参数不合法、设备被限、号码命中规则，对外都回同一句稍后再试，别让人拿错误提示反推规则。
注册页对这种校验的耐心通常只有两三百毫秒。同地域部署时，代理层自己加的那一跳多在几十毫秒，真正吃时间的是服务方响应和你的重试次数。
超时要在代理层定死，并且短于前端预算；超时之后必须能降级放行——查不出来就按正常号码走完注册，结论异步补上。反过来，让前端在失败时重试三次，一个弱网用户能在注册页卡上半分钟，还顺手把配额烧掉一截。
灰度也放在这一层做：先在一个入口放量，观察一两周的无结论比例与延迟分布，再推到全部入口。号码状态查询接口上线：灰度、开关与回滚列过开关要覆盖哪几处。
四个问题：凭据是不是只在服务端存在；代理层有没有做裁剪和双维度限流；超时降级之后用户还能不能把流程走完；出了问题能不能在一处关掉。
前三个答是，最后一个答能在一分钟内，这套结构就站得住。答不上来的那一条，通常就是上线后第一个故障的位置。
还得认清能力的边界。接口查的是三家基础电信企业的在网状态，临时插在设备上的物联卡、由虚拟运营商放号的那批号码、号码本身登记在境外的，都不在可查范围内。代理层做得再厚，也不会让它们返回结论；名单里这类号码占比高，该在清洗环节单独标出来，别指望查询阶段兜住。能力侧的事实是：直连移动、联通、电信，八种状态加携号转网识别，按次计费、即买即用，鉴权走请求头携带 AppCode，字段与错误码以商品详情页文档为准。【手机号在网状态 API】的商品页可以直接对照，比自己照着场景猜接口形状稳。
文章评论
发表评论
请先注册/登录后评论