请教一下，关于后台发送短信验证信息的问题。

能容忍的话直接给前台返回失败，让用点重新发送 或者直接不给前台返回，给个倒计时，时间一到 让用户直接重新发送

一般都是存到 session 的，真的保存不到的情况，应该直接报错，还有现在的短信验证都有验证接口的，根本无需本地保存

所以不都是有个 60s 重新发送吗？

所以需要把手机号码和验证码做持久化！

颠倒一下咋样？先存缓存，存失败直接返回 或者异常捕获重试，发送失败清理刚才的缓存

我们是直接存到 session，不过 session 是放 redis 里的

前台做一个限制吧，就拿我用 redis 做缓存来说，这个缓存失败的概率是微乎其微的

缓存成功的话再去调用短信接口。话说楼主要不要考虑我们家的短信接口。

写入缓存失败的概率应该比调用第三方短信接口的失败概率还低。
我们的做法是直接返回成功，然后异步调用第三方短信接口，如果失败则 retry，再失败就不管了。
最后加一个预警，如果单位时间失败次数过高会通知开发

我是先放 redis，ok 了发短信。
如果用户再次发送，会先生成一个新的覆盖 redis 再发送。

我觉得调接口发短信失败几率更大点，所以跟你一样先存再发

短信验证码，不一定能保证完全发送到的，可以考虑 60 倒计时，没有收到，允许用户重新发起；同时，后台，也可以适当重试，比如，如果失败，则重试 3 次，一般都是调用第三方的短信接口，不一定能保证没底调用都没有问题；
交互上，需要产品稍微设计一下；

先存再发 检查时间 没过 60 秒 就还用这个发
别发送成功 再存 感觉很蠢。。
还有记得加 验证什么的 要不然被刷了 好惨