前言：
现如今登录用手机验证码登录是越来越常见了。虽然会增加成本，不过对用户体验的提升还是很有帮助的。那么，当产品经理对开发说，来按照这个原型给我搞个短信验证码登录的时候。我们作为研发，应该想些什么？
短信登录要做的事情
这里的图只展示了一次成功的流程。还有很多细节值得展开讲下。除了短信验证的流程以外，登录的安全性也必须要考虑到。尤其是比较重要的后台项目。
下面我就想图中17个步骤拆开分析
请求获取验证码（1~4）
1~4步主要的点有两个。
- 前端对手机号的格式验证，按钮多次点击的验证
验证规则可以宽松一点。虽然前端的验证并不可靠，但是不代表前端的验证没有用。同时，当点击了获取验证码后需要将验证码的按钮禁用，防止多次点击 -
后端对请求验证码的频率的限制
请求验证码频率限制
后端的部分则需要判断当前ip，当前手机号是否是重复请求验证码。这里就需要引入重复请求验证码的规则。一般的规则是60秒内可以再次请求。这个时间可以通过记录一条键名为请求手机号的一条缓存，过期时间为60秒。如果可以拿到值，则说明还没有到60秒再次请求。
验证合法性（5~8）
5~8步主要是验证手机号背后的用户的合法性
首先手机号的格式是必须要判断的，虽然前端有判断。但是后端的验证才是可靠的验证。后面就是通过手机号查库。查询的逻辑主要为
- 注册用户中是否有这个手机号
- 该用户状态是否为禁用
-
该用户权限是否可以登录当前业务
验证合法性
如果条件满足就可以进行下一步了
制作/存储验证码（9~10）
制作验证码，就必须考虑两个问题，1是验证码的长度 2是验证码的复杂度
对用户最友好的当然是纯数字，验证码越短越好。但是这样对安全性就大打折扣。有没有又对用户友好，又安全的方案呢？
答案是有的。我们先按照4位数字的方案制作，安全性的解决方案，在验证的部分来分享
发送验证码给用户（11~12）
这步就比较简单了。只需要按照SMS的接口文档，传入手机号，短信模版，验证码就可以发送了。可以考虑增加一个日志记入数据库，用作数据分析。
但是还有一个容易被忽略的问题。那就是短信防刷，我们之前的设置，都只是针对于一个手机号的防刷。还有一种刷短信是不停的更换手机号来刷的那种。解决方案可以通过，ip，ua，referer,header等参数来判断是否是同一个客户端发起的请求。如果是同一个客户端在一个小时内请求超过了5次。就必须通过极验，或者输入图形码。这样的话可以最大限度的防止别人对我们的系统进行攻击，同时也保障了体验不打折扣
验证登录,登录成功（15~17）
上面提到我们选择使用4位数字的验证码，如果不设置尝试次数的限制的话，黑客使用多线程工具，在短时间内进行暴力请求，最多1万次就能穷举出所有的可能，而且运气也不一定会这么差。有可能在3000次的时候就试出来了。
那么我们的解决方案就是。同一个手机号，验证三次。就将验证码失效。在3次失败后，第四次请求，就返回错误文案 “验证码连续错误三次，请重新获取短信验证码”
还有一个需要思考的维度。那就是短信验证码的有效期。一般来说，短信验证码会有5分钟的有效期。这里就会有一个交叉的问题。比如一个用户获取到了一个验证码而不去验证，过了60秒又去获取一次。他就会有两个有效的验证码。这样明显是不合理的，那么我就需要在获取第二次验证码的时候废弃调第一个验证码。使用缓存存储验证码的时候，直接set就可以将上一个验证码给覆盖掉，还可以重新设置5分钟的有效期。
验证登录这步主要是要完成之前提到的。验证3失败3次废弃验证码（无论是否匹配），验证通过后也要废弃验该验证码。同时验证码通过之后还是需要再次验证用户的合法性。防止比较极端的情况，比如请求验证码的时候用户是合法的，但是在5分钟之内用户被禁用了。这样的话还是不能让他登录。
登录成功的话就看自己的架构设计了。可以是token令牌也可以是session会话。建立会话之后，就算完成了一次完整的短信验证码登录了！~
总结
总结完成之后，就可以按照要求进行开发了。虽然是一个简单的短信验证码，但是我发现市面很多的项目，这一块都没有做好（别问我，我怎么知道）我们作为研发人员，一定要尽可能的考虑周全，以免出现线上事故。
