在注册流程中集成手机号有效性检查:四分支模型

先在免费沙盒中跑通流程,再准备生产接入。

统计选择在本站复用,可随时关闭;账号关联另行同意。

在注册流程中集成手机号有效性检查:四分支模型

注册表单把手机号发送给检查服务,却没有得到一个干净的通过结果。你需要决定注册代码下一步做什么:继续、重试、转人工审核,还是交给你已经在使用的OTP服务商。本文逐一讲解可下载示例中的四个合成分支,列出确切的fixture输出,并把示例已实现的行为与你的应用需要自行设计的部分区分开。文章还说明为什么号码有效性不等于持有证明或身份证明,尤其是在当前的免费生产路线中。

curl https://gridzen.ai/console/api/quickstart/trial \
  -H 'Content-Type: application/json' \
  -d '{"task": "signup_phone", "scenario": "success"}'

接入指南

问题:一次调用,四种含义

很多注册处理逻辑把手机号检查简化为通过或拒绝。一旦检查无法给出答案,这种捷径就会失效。结果可能是未知,也可能是服务商调用失败。把两者都拒绝,会把暂时的信息缺口变成流失的注册;把两者都放行而不安排下一步,则是把缺失的证据当作成功。你的决策是把结果视为四个分支而不是两种结局,并为每个分支指定负责环节。示例将其建模为normal、unknown、provider_failure和otp。每个分支都返回mode为synthetic_fixture、otp_sent为false、live_line_type_available为false。真正需要关注的字段是state、valid、line_type和next。

有效性不是持有,也不是身份

手机号检查描述的是号码本身。它不能证明正在输入的人控制这个号码,不能证明号码能收到消息,也不能说明这个人是谁。持有证明需要单独的验证,例如由你现有服务商发送的OTP;身份证明需要单独的身份核验。当前的免费生产路线Basic Lookup面向符合条件的企业,作为应用的辅助功能提供,技术速率限制为每分钟60次请求。它不请求线路类型、号码归属、可达性,也不发送OTP。因此fixture的normal分支中line_type为mobile只是合成值,而live_line_type_available始终为false。不要在免费路线上构建依赖线路类型的规则。

假设场景与预期fixture输出

假设:一个小型B2B工具在创建账户时加入手机号字段,并在接入任何真实查询之前先在本地运行四个分支。示例需要Python 3.10或更高版本,无需凭据,也不访问网络。预期输出如下:normal返回state为simulated、valid为true、line_type为mobile、next为continue_customer_policy。unknown返回state为unknown、valid为null、line_type为null、next为review_or_existing_otp。provider_failure返回state为unknown、valid为null、line_type为null、next为bounded_retry_then_review。otp返回state为unsupported、valid为null、line_type为null、next为customer_otp_provider。注意unknown与provider_failure的state和valid完全相同,只有next能区分它们。你的代码必须依据next分支,而不能只看valid。传入不受支持的分支名会抛出UNSUPPORTED_FIXTURE。

不自动拒绝的失败处理

以下是建议的应用设计,并非示例已实现的行为:对于unknown,让注册保持待处理状态,并加入人工审核队列;如果你的策略允许,也可以请现有OTP服务商做一次持有验证。对于provider_failure,按固定的少量次数并带间隔重试,之后转入审核,绝不无限循环。对于otp,调用你自己的OTP服务商;fixture从不发送验证码,otp_sent始终为false。对于normal,执行你自己的业务策略;valid为true只是一个输入,不是批准。每次尝试都记录分支和next值,让审核人员能看到注册为何暂停。示例只给出下一步的名称,重试次数、审核队列和OTP调用都属于你的应用。

示例能证明什么,不能证明什么

已实现:一个本地函数,为四个分支返回固定的合成结果,以及覆盖模拟状态转换的工程测试。未实现:任何真实查询、服务商适配器、OTP发送或真实线路类型。这些测试不能证明生产环境成功、外部采用情况或真实路线可用性,真实路线可用性需要另行确认。本地运行通过只说明你的处理逻辑能正确读取字段,并不代表真实号码已被检查,也不代表存在任何业务许可。

验收清单

接入真实路线之前请确认:一、四个分支都能在本地运行,且与上述预期输出一致。二、处理逻辑依据next分支,把valid为null视为尚无结论,而不是无效。三、unknown和provider_failure绝不会导致自动拒绝。四、provider_failure有明确的重试上限,之后转入审核。五、otp分支调用你现有的服务商,界面绝不假设检查服务已经发送了验证码。六、没有任何规则依赖免费路线的线路类型。七、记录中从不把有效号码标记为已持有或已核验身份。八、请求速率保持在每分钟60次以下。九、在任何真实注册依赖该路线之前,已单独确认真实可用性。

运行已检查的模拟示例

下载并解压 https://gridzen.ai/downloads/verification-delivery.zip,进入 verification_delivery,用 Python 3.10+ 运行。此本地示例不联网;独立身份实验请使用新的数据库。

python3 delivery.py phone --branch unknown
python3 delivery.py phone --branch provider_failure

来源与范围

https://gridzen.ai/guides/signup-phone-check/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟;建议的业务规则属于设计建议,不代表已证明的生产行为。内容使用 AI 辅助写作,并经过独立审稿。

另行体验三种沙盒结果 创建账号,继续项目接入

下载不等于运行成功;本地示例与在线沙盒分别测试。

接入你的应用

运行三种模拟结果 · 需要接入帮助

连接免费沙盒账号

号码基础有效性不证明持有权或送达,不提供短信验证码。业务放行由你的系统判断。