从简单的功能探寻背后的技术。

故事

昨天看到一个地址，新用户免费领取X登读书APP的14天会员，2020年了，要开始读书了。看到这个活动是在笔记本上，于是用笔记本浏览器访问活动页面，输入手机号，收到验证码，填写验证码，领取这个会员。本来以为一切就是这样顺利的结束了，然而并不是，填写验证就提示“网络错误”。这不科学啊，作为程序员，我下意识的按了一下F12，打开了开发者工具，于是看到了下面的错误，如图：

将错误单独截图出来：

简单一点就是出现了跨域的问题。我想了一下，那估计这个活动是针对移动端的，我用PC端访问导致出现跨域。这个地方设计不好。

于是用手机去访问活动页地址，正常打开，然后填写手机号，然后提示：

我刚才PC发了几次验证码，这个地方设计还是考虑到安全性了，不错。

我只能等待，在开发角度，这个就是在一个固定的时间周期内，我的手机号只能发固定次数的验证码，超过这个数量，就不会给我在发了，一个是安全考虑，另一个可能也是费用考虑（ 防止短信验证码被刷 ）。

过了一段时间，我在去手机端试着领取，发现一切顺利，领取成功。

看到这里的伙伴如果是新用户，也对读书有点兴趣，那可以领取这个会员体验一下。地址：http://t.cn/AiFfyICx

到这里本该就结束了，但是作为一个开发人员，我觉得要简单整理一下这个发短息的功能，因为这个功能虽然看似简单，里面深究起来也有很多地方需要注意以及考虑的。

短信验证码设计总结

互联网的时代，发送短信验证码已经作为很多产品中必不可少的一个功能。用于的场景也是很多，如注册登录、银行转账、营销活动等（真的有很多场景，我就不多举例了）。

那在发送验证的时候，其实很多公司用的都是第三方的短信服务，这个短信的服务是需要收费的，天下没有免费的午餐。那么就出现 刷短信的黑工具——短信轰炸机 。

短信轰炸机就是一个利用写好的程序来大批量刷短信的软件，它能够通过自动批量提交手机号、模拟IP等方式去刷短信。

如果 需要用到短信验证码的产品的时候，一定要制定限制规则 ，做好设计。

主要原则：发送验证码是前端和后台是需要共同设计的，这样相对才能更加完善或者更加完美。
主要思路：

1、时间限制

xx秒后才能再次发送

一般点击验证后，在前端（客户端）会进行一个xx秒的倒数（这个倒计时可以根据具体产品具体业务定，很多是60s）。在这固定的时间内，用户是无法提交多次发送信息的请求的。

具体时效限制要考虑产品本身属性，操作难易度，网络延迟，短信资费成本等。

2、图形验证码限制 + 时间限制

（1）、在需要发送验证的码的时候，先让用户输入验证码，当输入的验证码通过后，才能请求获取短信验证码，否则获取验证按钮不激活。
（2）、在请求获取验证后，一般在前端（客户端）会进行一个xx秒的倒数（这个倒计时可以根据具体产品具体业务定）。在这固定的时间内，用户是无法提交多次发送信息的请求的。

这一点，图形验证码不一定是必须的。可能为了有更好的用户体验，一开始不需要输入图形验证码，在操作达到一定量之后，才需要输入图形验证码。具体情况请根据具体场景来进行设计。

这种方法虽然使用得比较普遍，但是却不是非常有用，技术稍微好点的人完全可以绕过这个限制，直接发送短信验证码。
如果前台倒计时60s，后台验证码的失效时间设计肯定不能是60，一般会是5~10分钟。

3、手机号+指定时间可以发短信次数限制

同一个手机号，指定时间之内不能够超过x条。

对使用同一个手机号码进行注册或者其他发送短信验证码的操作的时候，系统可以对这个手机号码进行限制，例如，24小时只能发送5条短信验证码，超出限制则进行报错（如：系统繁忙，请稍后再试）。然而，这也只能够避免人工手动刷短信而已，对于批量使用不同手机号码来刷短信的机器，这种方法也是无可奈何的。

4、IP及Cookie限制

限制相同的IP/Cookie信息最大数量

使用Cookie或者IP，能够简单识别同一个用户，然后对相同的用户进行限制（如：xx时间内最多只能够发送xx条短信）。然而，Cookie能够清理、IP能够模拟，而且IP还会出现局域网相同IP的情况，因此，在使用此方法的时候，应该根据具体情况来思考。

这样在第三点的基础上防止恶意刷手机验证码短信,如果同一个ip多次请求获取手机验证码短信，因为短信需要钱，竞争对手很可能恶意刷去。（我们对他人心怀善意，但是内心要有防备之心）

5、短信预警机制

监控短信服务，做好出问题之后的防护

以上的方法并不一定能够完全杜绝短信被刷，因此，我们也应该做好短信的预警机制，即当短信的使用量达到一定量之后，向管理员发送预警信息，管理员可以立刻对短信的接口情况进行监控和防护。

当我整理了相关的资料后，稍微明白了今天上文出现的问题，移动端验证码正常验证，而PC端不能进行验证的原因。可能是产品设计上的限制恶意刷短信，做了跨域请求限制。 也或许这就是一个bug。

后记

一个看似简单的功能，要简单做可以很简单，要复杂也可以很复杂，作为一个技术人员，了解业务，了解使用场景，了解用户量等，全面考虑，多端的时代，兼容性等也要考虑。

其实这个问题如果可以仔细想清楚的话，如果以后遇到就能够全面考虑，并且开发人员总是说自己做增删查改，这个的功能设计好，里面涉及了增删查改，更涉及了一个开发对功能的设计能力。

做好每一个小的功能，从小的地方提升用户体验，是产品和开发共同的责任。

最后在说两点，看到的朋友思考下：
1、后台应该如何处理验证码，保存在什么地方，内存，缓存，还是数据库？
2、怎么样的短信验证码用户体验好，内容和验证码长度？

欢迎留言，一起探讨交流~

手机验证码很重要，请不要泄露给陌生人~