叶佳桐做了这么多年后端，我一直觉得短信验证码属于那种“看着简单、做起来全是坑”的功能。用户只看到“输入手机号→收到验证码→填进去成功登录”这一套流程，但站在开发者角度，你面对的是业务校验、厂商对接、模板签名、缓存策略、防刷、回调、幂等、重试、日志排查一整条链路。很多项目第一次做验证码功能时，会想当然地以为“不就是调一下短信接口吗”，结果一联调就发现各种莫名其妙的问题——要么发不出去，要么发重复，要么签名字段对不上，要么测试号码收到了一堆信息，线上却一条都发不出来。
这篇文章把我在实际系统中接入短信验证码的完整过程写透，从需求评估、服务商选型、接口结构设计，到验证码存取、回调处理、联调排障，再到上线后的监控要点，一条线串下来。适合正在做用户注册、登录、安全验证、消息通知的后端开发者和全栈工程师参考，也适合系统还没开始设计、正在评估方案的技术负责人。文章里的代码和思路我尽量用通用伪代码配合情景说明，你拿到自己项目里可以按同样逻辑落地，不一定非要照搬某个SDK。
1. 接验证码前先做的需求推演：短信不是“发出去”就完事
1.1 先从业务场景倒推技术需求
很多开发接到“接入短信验证码”时的第一反应是去翻短信服务商的开发文档，这顺序其实是反的。你首先要搞清楚验证码在系统里到底服务哪些场景，比如：用户注册时校验手机号真实可用、登录时做二次认证、找回密码时验证身份、敏感操作时做操作确认。不同场景对验证码频率、有效期甚至文案都可能有不同要求。
我当时接的这个项目，场景有四种：注册、登录、找回密码、修改绑定手机号。把业务场景列清楚后，才发现有两个被忽略的隐藏需求：
- 找回密码场景下，用户可能没有登录态，需要校验的是“手机号是否在系统内注册过”，没注册的要给出明确提示，而不是直接发验证码。
- 修改绑定手机号场景下，要给“新手机号+旧手机号”两条验证码流程，顺序一错就会出现安全隐患。
这些需求如果不提前梳理，直接开会发号施令“所有场景统一发验证码”，到测试阶段绝对会出幺蛾子。
1.2 把技术约束条件在动手前定下来
业务需求明确之后，马上要定一套技术约束参数。下面这几个指标如果在设计阶段不定清楚，代码写完了再改，成本会成倍增加：
- 验证码有效期：我后来定为5分钟。太短用户会急着输错，太长又不安全。你可以按业务调节，但一定要在配置中心或者常量里留扩展位。
- 同一手机号每日发送上限：一般建议10条左右，特殊活动可临时调白名单。
- 同一IP每小时发送上限：针对攻击者换手机号刷接口的情况，一个IP不能无限请求。
- 同一手机号发送间隔：通常定为60秒，避免用户手滑或恶意反复点击。
- 允许校验错误次数：验证码输入错误达到5次就作废，需要重新获取。
- 图形验证码前置：高频场景或风险时段前要加图片滑块验证，否则短信接口很容易被脚本刷爆，一天烧掉几百块。
这些约束不仅影响防御和费用控制，也直接影响你后面积分/Redis的key设计。如果一开始没想到这些，后面突然说“我们这个验证码老被刷”，那可就只能加班补墙了。
1.3 明确发送成功不等于送达，回调状态必须进设计
我见过不少项目把“短信SDK返回OK”当成“用户一定能收到”。这实际上是两个完全不同的含义。短信服务商返回SDK调用成功，只代表它接收了这条发送请求；最终用户能不能收到，还取决于运营商网关是否下发成功、手机有没有拦截、号码状态是否异常的。部分高质量的短信产品会提供状态回调报告，这个回调在正式项目里必须处理，至少要留一个接收和记录状态变更的接口，否则你排查“用户没收到验证码”只能靠猜，怎么猜都猜不准。
功能设计到这里，你就有了一张进代码前的整体蓝图：一个发送入口，多条业务校验规则，一套验证码存储结构，一个回调接收逻辑，外加一个能查询发送记录的兜底能力。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务商接入与账号初始化：AccessKey和模板签名那几道坎
2.1 选服务商不能只看单价，要看这五个硬指标
国内做短信的服务商很多，像阿里云、腾讯云、容联云、七牛之类，甚至还有一堆短信通道代理商。选型时不要只看每条短信几分钱，重点看下面五项：
- 到达率与稳定性：价格再便宜，发出去十条丢两条，验证码业务直接没法用，用户收不到验证码会反复点击，反而推高发送量。
- 审核能力与备案模板效率：服务商对新签名的审核是否及时，模板审核要不要人工介入。有的小服务商审核奇慢，你活动周五上线，模板周四还没过审，项目只能干等着。
- 是否提供状态回调：有的服务商不提供异步报告，你根本拿不到发送后的真实状态，排查问题难度很大。
- SDK和文档质量：文档乱、示例老、接口都不支持新版TLS的服务商，接入成本高到让你怀疑人生。
- 计费和套餐外扣费上限：一定设置好日/月预算限额告警，防止某天接口被刷导致报警甚至收到巨额账单。
我当时的选择落地是：如果有大厂账号就直接用成熟云厂商的短信服务，因为公司内已经有了统一云账号体系，审计和开发文档也都成体系；如果项目比较小众、预算有限也可以考虑专业短信服务商，但务必确认对方支持回调能力和高并发场景稳定度。
2.2 签名与模板的申请逻辑：被驳回大多是因为“看着就不像正规业务”
短信内容不是你想发什么就发什么。在服务商控制台需要先申请“短信签名”和“短信模板”，审核过了才能调用发送接口。签名一般是【XX科技】这种，模板则是“您的验证码为${code}，${minutes}分钟内有效，请勿泄露”。模板里的变量要用服务商指定的占位符，接口调用时再传入真实参数。
第一次做容易在这两个地方翻车：
- 签名被驳回：常见原因是签名与主体资质不符。你没备案的App名字不能用，个人开发者想申请企业签名难度大。解决办法是用“已备案的网站名”或“已认证的小程序名/公众号名”来申请。
- 模板被驳回：多数是文案过于模糊、有诱导性或者包含测试字样。某个模板变量不能放URL，不能把整段验证码都塞进变量，变量长度还有限制。我建议文案写清业务名称和用途，比如“【某云系统】您正在登录账号，验证码为${code}，5分钟内有效。如非本人操作，请忽略本短信”，这样审核基本一把过。
2.3 AccessKey管理：密钥一旦泄露，比用户验证码泄露还麻烦
所有服务商都会要求你用自己的AccessKey ID和AccessKey Secret请求签名认证。这里有个开发习惯必须强调：密钥绝不能出现在代码仓库里，更不能硬编码在前端。正确做法是放在服务端环境变量或专有配置中心，最好走密钥管理系统动态读取。如果发现代码仓库里曾提交过密钥文本，哪怕是私库也要立刻轮换密钥，因为Git历史中的泄露不会因为后续删除而彻底消失。
我在实际项目中碰到过同事图省事把AccessKey Secret放在Spring Boot的application.yml里，结果提交到了公共代码仓库，好在是内部仓库且及时轮换，不然短信通道被刷的费用全部得由公司承担。这类问题属于不出事则已，一出事就是大事故的典型。
3. 发送接口的代码结构拆解：给不同厂商留出统一出口
3.1 不要在一堆业务代码里直接new Service的Client
现在很多短信厂商提供了SDK，用法也很简单。你可能会看到一些项目在Service类里直接写“AlibabaSmsClient client = new AlibabaSmsClient(...)”，调用发送方法，然后就认为万事大吉。然而一旦要换服务商、要做双通道灾备或要给测试环境打桩Mock，这种写法会让人非常痛苦。
更好的做法是先定义一个内部短信发送接口，业务层只依赖这个内部接口，不直接依赖厂商SDK类型。伪代码如下：
java复制public interface SmsSender {
SmsSendResult sendVerificationCode(String phone, String signName, String templateCode, Map<String, String> templateParams);
SmsSendResult sendMessage(String phone, String signName, String templateCode, Map<String, String> templateParams);
String getProviderType();
}
厂商SDK的逻辑封装在独立的实现类中，例如阿里云建立一个AliyunSmsSender，腾讯云建立一个TencentSmsSender。业务层拿到的是一个抽象的SmsSender，并不关心它背后到底是哪家服务商。
如果你项目中用Spring，可以用一个Map来管理多个Sender实现：
java复制@Component
public class SmsSenderRouter {
private final Map<String, SmsSender> senderMap;
public SmsSenderRouter(List<SmsSender> senders) {
this.senderMap = senders.stream()
.collect(Collectors.toMap(SmsSender::getProviderType, Function.identity()));
}
public SmsSender getSender(String providerType) {
return senderMap.getOrDefault(providerType, senderMap.get("default"));
}
}
这样切换服务商的时候，改动只在路由配置层，业务代码不用大改。万一某家服务商连续失败，还可以靠配置中心动态把providerType切到备选通道。
3.2 抽象发送结果的细节：返回的不是“成功失败”两个字
短信发送结果如果只返回一个布尔值，那对后续排查基本没帮助。我建议定义一个统一的结果模型，至少包括这几个字段：
- 是否调用成功：代表请求是否被服务商网关受理。
- 服务商请求ID：用于后续查服务商日志。
- 服务商错误码和服务商错误消息：如果发送失败，错误码是定位问题的第一信息源。
- 状态枚举：包括受理成功、解析失败、服务商拒绝、未知异常等。
用伪代码写就是这样：
java复制public class SmsSendResult {
private boolean requestSent;
private String requestId;
private String errorCode;
private String errorMessage;
private SmsStatusEnum statusEnum;
}
这里尤其要注意“未知异常”分支。很多SDK抛出的RuntimeException直接向上抛，导致前端收到“系统错误”，而你却拿不到任何定位信息。最稳的写法是捕获所有异常并转化为SmsSendResult，日志里打印异常堆栈，同时返回给上层一个明确的错误码。用户看到“系统繁忙”没关系，你千万别让自己也是“系统繁忙”。
3.3 模板参数与动态字段的映射
每家服务商的模板变量要求不一样。比如阿里云老版本可能要求参数直接塞JSON字符串，新版本支持直接传入Map。但公共逻辑是：模板变量必须精确匹配。你在控制台模板里定义了${code}、${minutes}，代码里传的参数名也要是这个，多传、少传或者名称拼错，服务商都会返回模板变量不匹配。
这里我吃过亏：模板里写的是${code}，代码里却突然传了一个verificationCode的key，结果服务商返回“变量与模板不匹配”。排查半天才看到错误。所以最好把模板Code和变量名写在配置里统一管理，让运维也可以调整。要特别注意minutes是字符串，不是整数，有些SDK序列化时会转错类型。
4. 验证码存储与校验的设计：别把数字往表里一塞就了事
4.1 为什么选缓存而不是数据库表
验证码是典型的“短生命周期、高频读写、写入紧张、过期会作废”的数据。放在MySQL里不是不行，但会有几个尴尬问题：用户请求校验时需要把过期数据也捞出来判断；验证码过期后还留在表里变垃圾数据；单次恶意请求会导致大量写入和查询。用缓存解决才是主流方案。如果你项目里有Redis，那很合适。如果没有Redis，用内存Caffeine/Guava Cache也能对付单机或低并发场景，但集群环境多实例部署时必须谨慎，因为用户两次请求可能落到不同实例，内存缓存会互相不认。
以Spring Data Redis为例，存验证码时可以用这样的Hash结构：
java复制String key = "sms:code:login:" + phone;
HashOperations<String, String, String> ops = redisTemplate.opsForHash();
ops.put(key, "code", code);
ops.put(key, "expireAt", String.valueOf(expireTimestamp));
ops.put(key, "verifyCount", "0");
redisTemplate.expire(key, Duration.ofMinutes(5));
也可以用更简单的字符串结构，比如直接存code + ":" + phone的对应关系，但Hash的好处是能顺便存尝试次数和首次发送时间，方便校验的时候一把取出来判断。
4.2 校验逻辑的先后顺序不能乱
校验验证码看起来就是“用户传一个code，我比对一下缓存，相等就给过”，但实际上真正的顺序要复杂一些：
text复制1. 根据场景和手机号拼装缓存Key，查询是否存在对应的验证码记录。
2. 记录不存在：直接提示“验证码已过期，请重新获取”，不要多解释是否手机号没发过。
3. 记录存在：先检查错误次数是否达到上限，如果达到上限则返回“错误次数过多，请重新获取”并删除该记录。
4. 对比传入的验证码是否和缓存里的验证码一致（推荐用恒定时间比较规避时序攻击，虽然短信验证码不涉及极高价值资产，但好习惯可以先养成）。
5. 如果一致：立即删除验证码对应的缓存Key，明确验证码是一次性的。
6. 如果错误：错误次数加一，并返回给前端“验证码错误，还可尝试x次”。
关于“5”这个细节，很多项目会漏掉。用户收到验证码后可能在多个页面同时提交，如果不做一次性消费，旧的验证码可以反复用，严重时甚至会出现“A拿到了手机验证码，B也能用同一个验证码验证通过”这种漏洞。验证码必须在第一校验成功后立即失效。
4.3 防刷不能只靠验证码本身
验证码本身就应该防止被暴力破解，所以错误次数限制和有效期约束都很重要。但更值得留意的是发送频率限制。一个恶意的调用者可以在没有图形验证码约束的情况下，用程序循环请求你的发送接口，对同一个手机号或一批随机的手机号不断下发短信。短信是按条计费的，一旦被打，那就是真金白银的损失。
在网关层加个前置逻辑其实不复杂：
- 同手机号60秒内只允许发送一次；
- 同手机号每天最多10条；
- 同IP每小时不超过一定条数；
- 如果请求量突增，可以再叠加一个简单的计数限流器。
这里放在代码里实现也可以。比如用Redis的INCR加EXPIRE做计数，或者使用分布式限流组件。团队里有条件就统一走网关层限流，没条件就在业务Service里手写一套。核心目的是避免绕过图形验证码后的无脑刷短信。
4.4 测试环境别用线上计费通道疯狂发验证码
这一点我要单独提出来说，因为太常见。测试人员在回归验证码功能时，用几个固定手机号反复点击发送，一天就消耗上千条真实短信，测试完成后运营看到账单直接崩溃。更难受的是，有些手机号确实会收到一堆测试验证码，容易引起投诉。
解决思路有三层：
- 测试环境用服务商提供的测试模板或测试签名，不发真实短信，只在日志里打印验证码。
- 代码中增加环境判断，比如
dev/test环境直接走MockSender，验证码固定输出到日志。 - 内网联调时配置一个“万能验证码”开关，仅限测试环境开启，生产环境强制关闭。这种做法容易引发争议，但只要保证生产不可访问且不开启，就能大幅提高测试效率。
在我参与过的项目里，测试环境统一走MockSender，不产生任何真实费用。回归测试报告里写“验证码为666666”，后端日志能看到，调试速度上了一个台阶。
5. 回调、状态机与幂等：收尾阶段最容易漏的部分
5.1 短信状态回调：别把它当可有可无
短信服务商在完成短信下发后，会向你的服务端发起一个状态回调，告诉你说这条短信“成功送达”或“用户手机号停机/空号/关机”，如果长时间不下发，也会有最终状态。这个回调接口从实现上看并不复杂，却能让运营人员看到更准确的发送量、到达率，也能在用户反馈“没收到”时直接定位是短信被拦截还是手机号有问题。
在设计回调接口时，需要用一个发送记录表做状态存储。每条发送请求入库，后续回调只更新这条记录的状态。这个发送记录可以是单表，字段如下：
- 发送ID（业务流水号）
- 手机号
- 业务场景
- 模板Code/签名
- 验证码（加密或脱敏存储）
- 服务商请求ID
- 发送状态（初始/发送中/成功/失败/超时/未知）
- 服务商返回状态报告
- 发送请求时间
- 状态回调时间
5.2 回调接口的验签与防伪造
回调URL如果暴露在公网，任何人拿到地址往你这边POST数据，都可以伪造短信状态。处理方式每个服务商不同，普遍原理是提供一个签名算法或Token鉴权。你必须用服务商文档中的公钥/Secret来校验回调来源。否则假回调一旦被业务状态机接受，可能导致“用户明明没收到短信却被标记为已送达”这类问题。
排除伪造之后，建议把回调参数逐条打印或入库保留。大批量业务突然出现到达率下降时，这些原始回调数据是分析被运营商拦截、通道质量下降的最重要依据。
5.3 回调更新记录时的幂等约束
服务商的回调可能会重复推送同一条消息，有些通道在超时后会重试多次。如果你直接按服务商消息ID更新发送记录，不处理重复请求，会出现状态被旧值覆盖、计数重复的问题。这里有几个办法：
- 数据表里给“服务商消息ID”建唯一索引，插入时捕获冲突，冲突则跳过。
- 如果消息ID不会重复，那可以在更新前判断当前状态是否已经是终态，如果是终态就忽略重复回调。
- 更保险的做法是在回调接口的实现里增加去重表或使用Redis幂等标记。
5.4 重试机制和MQ的选择
短信发送是一个外部依赖项，网络波动、服务商接口抖动是常态。对验证码这种实时性要求很高的业务，重试策略要小心设计：如果用户等验证码时你后台疯狂重试同一手机号，用户没收到验证码却收到了好几条，体验很差且浪费成本。
我建议：
- 对于用户主动触发获取验证码的请求，失败时直接返回错误，前台引导用户稍后点击“重新获取”。不要在同一请求内盲目重试三次，除非你确定是服务商短时抖动且重试间隔充足。
- 对于真正的异步通知类短信，可以考虑写入MQ或延迟任务队列做兜底重试，最大重试次数控制在3次以内。
扫码场景如果走短链接通知，更需要考虑重试与去重。因为同一业务事件可能反复触发，系统层要做“相同业务ID已经存在则不再新增发送请求”的处理，这就是幂等。发送流水表里给业务ID加唯一索引很常见。
6. 联调中常见的五类问题与排查实录
6.1 签名字段、模板Code不匹配
这类问题的特征是：你调用后服务商返回“InvalidSign”或“TemplateCode不匹配”。一般原因就是你在控制台申请的签名、模板和调用代码里填的不是同一个。不要在本地反复猜测，去控制台打开短信服务页面，把“签名名称”“模板CODE”“模板内容”三项逐一复制到你的配置里。
还要小心环境区分。服务商控制台可能同时存在多个AccessKey归属于不同主账号，测试用的服务商账号和生产账号申请的签名模板不是同一个，很多团队配置没切换导致两者混用。解决方案是在配置文件里为每个环境单独设置短信配置sms.signName和sms.templateCode，部署流程尽量自动化，别手动改。
6.2 手机号收不到短信，先分清是“没提交成功”还是“已提交但被拦截”
这个坑最耗时间。用户在测试页面点了发送，前端提示成功，但手机就是收不到。排查节奏应该是：
- 查看服务商后台发送记录和回调报告，看这条短信到底有没有受理、有没有下发。
- 如果状态报告显示“送达”，但用户没收到，多半是手机安全软件拦截或运营商拦截。可以让用户翻一下短信拦截箱，或者检查这个号码是否曾经投诉过广告短信，被运营商列为重点拦截对象。
- 如果状态报告没有返回，联系服务商技术支持并给出消息ID，让通道方排查。
有一个很反直觉的经验：测试时不要用170开头的虚拟号段收短信，虚拟号段在运营商的短信下发成功率天然偏低，不是你的代码问题。要用三大运营商的常规号段做主力验收。
6.3 本地请求服务商接口超时，问题可能出在代理或白名单
很多公司办公网需要走代理出网，服务商SDK默认不走代理时就会一直连接超时。另外，部分服务商要求配置IP白名单，你本地开发机的出口IP如果不在白名单内，请求会被拒绝。但每次本地IP变了就要改白名单，非常麻烦。
更顺滑的做法是：本地Linux环境单独建一个DNS转发或代理脚本，把短信请求通过测试服务器转发出去？不行，真要本地直连，最好是统一配置公司出口IP到白名单。更高频的做法是，需要本地联调时直接用测试服务器的端口转发到本机，然后手动用curl模拟发送请求，验证参数和逻辑。SDK集成问题可以先写单元测试桩，不依赖真实外网。
6.4 代码里验证码过期时间和服务商模板文案不一致
用户在短信里看到“5分钟内有效”，但Redis里却设置了10分钟；或者反过来，文案写着10分钟，代码设置了5分钟。这种不一致在功能上不会报错，但对用户体验有影响。尤其当用户在第7分钟输入验证码时，按文案是有效的，代码却判过期，用户就会反复投诉。
把过期时间统一收口到一个配置项，模板参数里的minutes也从这个配置读取，保证代码和短信文案同时使用同一个值来源。伪代码如下：
java复制int expireMinutes = smsConfig.getCodeExpireMinutes();
String templateParams = Map.of("code", code, "minutes", String.valueOf(expireMinutes));
这样做至少能避免“手改文案忘改代码”的低级问题。
6.5 并发发同一验证码导致记录互相覆盖
这种问题更多出现在前端没有做按钮倒计时，又恰好有多个页面入口。用户在同一秒点了两次发送，后端并发处理时生成了两个不同验证码，都写同一个缓存Key，后写入的会覆盖前面的。用户收到的短信可能是第一条，但Redis存储的可能是第二条，必然校验失败。
解决办法是发送接口整体加分布式锁，或者在业务代码里保证同手机号同场景的发送动作互斥：
java复制String lockKey = "sms:lock:send:" + scene + ":" + phone;
boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(60));
if (!locked) {
throw new BizException("操作太频繁，请稍后再试");
}
其实加了60秒发送间隔后，这个锁正好能和间隔限制合并实现，直接使用Redis的SET NX EX就行。
7. 上线后的运行时监控与几个容易被漏掉的细节改进
7.1 日志记录要为后续排障留出完整线索
短信业务线上出问题时，最痛的情况是用户说“收不到验证码”，你手上只有一堆“发送成功”的日志，却不知道用户到底用的哪个手机号、传了什么参数。从第一行代码开始就要规划好日志内容。发送接口的日志建议这样打：接入参摘要（手机号脱敏后四位、场景、签名、模板Code）、调服务商返回码、服务商请求ID、耗时。回调接口的日志要打全量原始参数和签名校验结果。用户主动校验验证码的接口也要记录，方便判断是用户输错还是验证码过期。
排查记录部分可以改进：每次生成验证码时，在日志中打印“验证码生成但脱敏”，生产环境不要打印完整验证码。但测试环境可以放开。完整验证码如要留存，在数据库加密存储或直接不存储，仅存放在Redis并设置过期时间。
7.2 监控指标：短信发送量、成功率、延迟、到达率
短信功能上线后，要盯的不是“接口有没有报错”这种粗糙指标。建议把下面几项在监控面板中置顶：
- 短信发送总数和环比增幅：如果今天发送量比昨天翻了三倍，先怀疑业务活动，如果没有活动则马上看是不是被刷了。
- 服务商调用成功率：这个指标下跌，大概率是通道问题或账号欠费。
- 到达率：这个数字依赖状态回调，如果回调突然断了，到达率会跟着失真。
- 单次发送RT：服务商接口响应时间过长，会拖慢用户获取验证码的整个流程。
我还习惯加一个“验证码校验成功率”的监控，它指“用户输入的验证码和Redis中完全匹配”的比例。如果这个指标异常低，要么用户普遍收不到短信，要么开发改坏了校验逻辑，要么就是有攻击者在撞库。
7.3 上线后常被遗忘的三个小改进
第一，验证码短信的文案里最好包含“若非本人操作，请忽略”之类提示，这样可以大幅减少“收到验证码但没操作”的用户投诉。第二，申请一个专用的发送账号和每月预算告警，预算达到80%时就告警，防止月初忘记充值和爆发费用。第三，如果公司有多条短信通道，建议设计一个切换开关。当主通道到达率或成功率持续偏低时，运维能够一键切换备通道，不用发版。短信服务商偶尔也会有大面积故障，有一个备选通道是保命设计。
另一个细节是关于“回调接口不响应”的。状态回调是服务商主动调你的公网接口，如果该接口没有做好安全校验，又或者被WAF误拦、返回非2xx，服务商的重试也会失败。上线后要专门跑一遍回调日志，确认服务器实际收到了回调并正常处理，而不是在测试环境用内网地址测一次就算完事。
7.4 从“能发验证码”到“把验证码体验做好”
短信验证码这件事做到这个程度，功能上其实已经可以交付了，但如果你愿意再往下钻一层，还能在体验和安全上做不少优化。比如获取验证码前先做人机图形校验，可以对短信轰炸防御起立竿见影的效果；比如用户输入验证码后可以在前端做一次长度和格式的预校验，减少无效请求；再比如把发送按钮的倒计时放到后端返回的剩余秒数里控制，不只靠前端本地判断，防止用户切后台后重新计时。
我做过的一个项目里，还加了“同手机号在短时间内从多个入口重复获取验证码时，发出是否继续操作的提示”的逻辑。这个功能一开始没做，后来运营反馈用户经常在找回密码和登录页面都点了发送，结果收到两条验证码，用户容易混淆到底用哪个。
接入短信验证码接口这件事，真正做完一遍后你会发现，它考验的不只是某个第三方SDK的调用能力，而是你对业务边界、异常处理、安全防护、数据时序和可观测性的整体把握。很多时候用户收不到验证码，问题的根因并不在代码本身，而在通道配置、模板审核和运营流程里。先把设计链条上的每个环节都想清楚，再动手写代码，比拿到需求就开始敲键盘要有效得多。