用占位符代替真实短信验证码测试注册流程，只能验证表单本身，验证不了完整链路：它捕捉不到投递延迟、某个服务特有的验证码格式，也捕捉不到确认邮件环节的中断。只有使用真实验证码完整跑一遍，才能确认从请求号码到登录账号，注册链路是否真正打通。
为什么需要真实验证码的完整场景
模拟验证码总是瞬间到达且格式符合预期——现实并非如此。运营商可能延迟投递 20–40 秒，验证码可能拆成两条短信而非一条，确认邮件也可能卡在邮件服务商的审核队列里。这些情况占位符都无法复现，而恰恰是这些情况最容易拖垮一个数月未曾改动过的生产注册流程。
第二个理由是整条集成链路。真实验证码测试核对的不只是短信解析，而是完整链路：通过 API 请求号码、把验证码投递到你这一端、从文本中提取验证码、填入表单、完成激活。任何一环断裂都是应该在 CI 中捕捉的缺陷，而不是留到生产环境暴露。
完整流程如何搭建
整个场景分三步。第一步，在目标平台开始注册前，通过 API 请求一个号码或邮箱。第二步，等待验证码：验证码不会瞬间到达，因此管道应按固定间隔轮询状态，而不是依赖单一的盲等超时。第三步，完成注册：把验证码填入表单，完成注册，并将该号码或邮箱标记为已使用，避免为一个不会再来的验证码重复发起请求。
等待超时应比正常投递留出余量：如果验证码通常 10–15 秒内到达，管道里设置 60–90 秒的超时才合理，而不是 15 秒。重试请求验证码，一次是合理的：第二次尝试能吸收偶发的运营商延迟，而第三次通常说明链路本身出了问题，而非投递波动。
为何应是独立的低频任务，而非每次提交都跑
真实验证码测试每跑一次都要花钱——无论结果如何，号码或邮箱都会被计费——而且依赖你无法控制其延迟的外部服务。如果每次提交都跑，就等于为分支上的每一次推送付费，还会因为外部投递延迟而不是代码本身产生随机的失败构建。
可行的做法是：把基于占位符的快速测试留在每次提交都跑的常规管道里，把真实验证码场景单独拆出，作为低频任务——发版前跑一次、按计划每天跑一次，或合并到主分支前手动触发。这样既能在投递链路上捕捉真实的回归问题，又不会拉高日常构建的成本和耗时。
测试数据与生产数据隔离
自动化测试用的号码和邮箱应来自独立的资源池，而不是与生产任务共用同一个余额：混用会让成本核算变得困难，还有可能让测试任务误占本该留给生产流程的号码。测试创建的账号应打上独立的前缀或邮箱域名标记，并按计划清理——否则测试记录会堆积在与真实用户相同的数据表里，干扰分析统计。
运行成本核算
每一次真实验证码测试，都是号码或邮箱的费用加上管道执行时间的成本。值得先算清一次完整场景的成本，再乘以运行频率：每天一次是一个预算量级，活跃分支上每次提交都跑则是完全不同的量级，成本会成倍上升却没有相应的收益增长。合理的目标是：让真实验证码测试的频率足以在发版前捕捉回归问题，又足够低频，使 CI 支出不至于反超服务本身的成本。
常见问题
能否完全用真实验证码取代占位符？
没有必要：占位符速度快、不花钱，适合在每次提交时测试解析逻辑和表单本身。真实验证码用于单独的完整场景，用来捕捉集成与投递问题，而不是用来在每次改动时测试应用代码。
如果验证码在超时时间内没有到达该怎么办？
先重试一次请求是合理的第一步——它能吸收偶发的运营商延迟。如果重试后验证码仍未到达，测试应该明确、清晰地失败，而不是一直挂起直到管道的整体超时——这样能节省排查时间，也能明确指向投递链路的问题，而不是偶然波动。
真实验证码测试多久跑一次比较合适？
比较实用的节奏是按计划每天跑一次，再加上合并到主分支前的强制一次。这样的节奏能在合理的时间窗口内捕捉回归问题，同时让号码和邮箱的支出保持可预测，不随开发中提交数量的多少而波动。
API 一侧号码请求与验证码状态轮询的具体方式见API 文档。第一次测试跑所需的号码可在OTP板块获取——通过 API 轮询状态的原理，与通过 API 配置 IP 轮换相同。日常运行的支出可在交易记录中追踪。