想起去年看到的一个社交项目的源码，短信验证码平台app这块是这么处理的，下面来详细的介绍一下。

用户从前端App请求发验证码短信之后，有一个倒计时一分钟。但是后端redis短信验证码会存在3分钟，然后如果在这个120s之后，用户没有收到验证码，点击重新发送验证码，短信验证码平台app会重新开始倒计时。短信验证码平台app

后端会检查这个用户是不是已经在redis里面有一个手机验证码了，如果有就不会发送了，也不给提示。如果第一次发送由于短信通道原因，没发送成功就会造成用户没有收到验证码。

但是redis里面确实存在一个有效的验证码的情况，那用户就非得等够五分钟之后redis里面的验证码失效了才能成功重发。

当时觉得这个设定太坑了，在App大量同质化的今天，短信验证码平台app多次重发之后都收不到验证码，有哪个用户会点了还会接着用这个App的。

这个地方我们之前是这么处理的，一般都是给有发送短信的手机号设定一个发送过几条短信的计数器。定时的清空一下，一般设定为一天清理一次。设定一个阈值，比如一天能发50条或者100条。

如果在这个阈值内，前端倒计时结束时请求重发短信，后端收到请求校验没问题后，正常发就行了。如果超过了这个阈值就不给发了，但是不发归不发，一个友好提示还是要给到用户的。