“请稍后再试”不等于“无效”：处理暂时无法给出结论的注册电话检查

问题与需要做的决策

“请稍后再试”告诉用户，验证系统没有得出结论，并没有说号码是错的。如果你的注册代码把所有非通过结果都当作失败，那么一次临时故障就会变成永久拒绝；用户也可能在毫无反馈的情况下无休止地重试。你需要决定三件事：第一，临时失败映射到什么状态；第二，允许多少次重试、间隔多长；第三，重试用完后案件流向哪里。fixture 不会替你做这些决定，它只给出一个下一步名称。重试预算、给用户的提示文案和人工复核队列都由你的应用负责。以上是建议的应用设计，并不是示例已经实现的行为。

fixture 实际返回什么

可下载的示例运行四个合成分支：normal、unknown、provider_failure 和 otp。它需要 Python 3.10 或更高版本，不需要任何凭据，也不发起任何网络调用。每个分支都会返回这些字段：mode、branch、otp_sent、live_line_type_available、state、valid、line_type 和 next。对于 provider_failure，预期输出为：mode 为 synthetic_fixture，branch 为 provider_failure，otp_sent 为 false，live_line_type_available 为 false，state 为 unknown，valid 为 null，line_type 为 null，next 为 bounded_retry_then_review。与之对比，unknown 分支同样返回 state unknown 和 valid null，但 next 为 review_or_existing_otp。只有 normal 分支返回 valid true、line_type mobile 和 next continue_customer_policy。otp 分支返回 state unsupported 和 next customer_otp_provider，并且不会发送任何验证码。传入其他任何分支名称都会抛出 UNSUPPORTED_FIXTURE。请注意，valid null 并不等于 valid false。这个 fixture 中没有任何分支表示“号码无效”，也不应把任何分支解读为拒绝。

一个假设的完整示例

设想一个假设的小型 B2B 注册表单：用户输入号码后，你后端的电话检查超时了。在沙箱中，你可以通过运行 provider_failure 分支来模拟这种情况。你提出的处理程序读取到 state unknown 和 next bounded_retry_then_review，因此不会把账户标记为拒绝。它会连同计数器一起保存这次尝试，并向用户显示一条中性的提示：检查暂时不可用，注册并未被拒绝。随后按照你定义的计划重试，例如固定的少量几次。如果这些尝试仍然返回 unknown，处理程序就把案件转入人工复核，而不是继续循环。如果你的策略允许用户先继续注册，那么所有依赖这次检查的操作都会被暂缓。这里的次数和时间间隔只是为了说明而做的选择，既不是 fixture 的行为，也不是推荐的生产参数。

需要明确说明的限制

该示例是合成的，绝不是真实的提供商适配器。normal 分支里的 valid true 只是预设数据，不能证明号码归属、短信可达性或身份。当前免费的生产 Basic Lookup 路由不会请求线路类型、归属、可达性或 OTP 投递，因此每个分支的 live_line_type_available 都是 false。使用该路由需要另行注册账户，并且有每分钟 60 次请求的技术速率限制。所以，用户集中重试反而可能让你自己的失败情况变得更糟。otp 分支建议使用你现有的 OTP 提供商，本身不发送任何内容。四分支下载示例与匿名的三场景 HTTP 试用并不是同一回事，不要把其中一个当作另一个的证据。

围绕 fixture 构建的失败处理

把“不可用”和“无效”保存为不同的状态，即使界面上的措辞相近也应如此。按每次注册和每个时间窗口限制重试次数，并保持在速率限制之内。记录每次尝试及其分支结果，方便复核人员了解案件进入队列的原因。绝不能让重试循环悄悄变成自动拒绝，也不能让它悄悄变成自动批准。要显式处理意外输入：在 fixture 中，不受支持的分支会直接抛出错误，而不是自行猜测，你的适配器也应如此。示例附带的工程测试覆盖了模拟状态转换、绑定、重复回调、重启和超时等情况，但这些测试并不能证明生产环境中会成功。

验收清单

运行全部四个分支，并断言上文列出的精确输出。确认 provider_failure 永远不会导致账户被拒绝。确认 unknown 会流向人工复核或你现有的 OTP 步骤。确认 otp_sent 始终为 false，并且你的代码不会等待一个 fixture 从未发送过的验证码。检查重试会在你设定的上限处停止，随后创建一个复核项。检查用户看到的提示不带指责意味。断言 live_line_type_available 为 false，并确保在真实使用中没有任何逻辑依赖 line_type。记录在案：沙箱通过并不等于真实的业务许可。如果这与你的任务相符，下一步是先运行合成教程，然后可以选择保存一个沙箱请求。真实路由是否可用需要另行确认。

运行已检查的模拟示例

下载并解压 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 辅助写作，并经过独立审稿。