DaisyWithCat

      验证码相对于信息架构流程设计等等，只是很细节的一个设计点，但偶尔也会让体验设计师感到头痛。

      首先了解一下为什么要验证码？

      图片验证码是防刷机制的一种，而防刷机制的本质就是区分到底是正常用户请求还是脚本程序。

      防刷也就是防止恶意攻击，即通过脚本或程序对服务器进行短时间大量请求，导致服务器无法为其他正常的用户请求服务。又或者恶意请求短信验证码，浪费短信资源导致成本提高。

      恶意攻击能在很多常见流程中找到漏洞，注册，找回密码等等。而对于一些运营活动，由于涉及到让利，则需要根据具体活动形式对防刷机制进行更复杂的考量。

      本文只在此阐述最为基本的防刷机制。 

      常见的防刷机制有这些：

• IP或手机号限制：对同一个IP或同一个手机号发送请求的次数进行限制。但是这种方法很容易误伤正常用户，比如局域网内的大多数请求都会使用同一个IP。

• 时间：例如发送验证码的时间间隔为1分钟（大多数产品使用了这个时间长度，而京东很独特地设置为2分钟=。=）

• 设备MAC：适用于App类，可以在发送请求时代入设备MAC码，发现有问题时，可以直接对该设备的请求进行限制。但是对于Web端的产品就没办法了╮(╯_╰)╭

• 图片验证码：最稳妥也是最有效的解决方案。因为机器识别图片中的文字并不那么准确，需要强有力的算法支撑，而即使被破解了，换个形式的图片成本低廉。例如12306丧心病狂的低像素图片验证码，不仅防住了机器，也防住了用户。 

      这些机制经常会结合起来一起使用，比如发送短信验证码时会限制1分钟只发一次，若同一手机发送次数已达3次，则会要求用户先填写图片验证码才能发送短信，如果次数达到10次，则24小时或48小时内将停止向该手机号码发送短信了。这是一个循序渐进的过程。

      那么能不能避免使用验证码呢？

      总则：能免则免。

      毕竟在流程中多增加一次输入，是很考验用户耐心的，体验差则可能会造成用户流失。

      但是大多数情况下是很难避免的。但是可以从设计的角度和技术实现的角度，让用户察觉不到走了验证这一步。 

      怎么使验证码体验不那么糟糕

      增加趣味性

      以淘宝为代表的一系列新型验证码，可能需要接入第三方验证码服务。

      而更为简单的google打勾验证码，必须使用google的服务才能实现。

      这些有趣的验证码体验确实不错，但是技术实现上是有一定难度的，在项目时间不允许的情况下会很难推进。

      推迟验证

      让正常的用户在体验时省去验证码的一步，这样大多数用户是不会需要输入验证码时。频繁请求（需要制定频繁的程度）时再加验证码防刷，虽然可能会有一定的成本风险，但保证了大多数正常用户的体验。:)

      一些tips

• 验证码图片可识别性尽量高一点，除非你的系统要与12306一决高下。

• 统一字符，让验证码不要区分大小写吧，要么使用英文要么使用数字，长度6位也足够防刷了。

• 使用相应的键盘，如果你的验证码都是数字，那么直接给出数字键盘会很贴心。 

• 即时反馈：填写完成之后，自动发送短信验证码，或者给出反馈告诉用户填写正确了。良好的反馈总会减少那么一点点焦躁。

• 验证码刷新：让用户手动自己刷新吧，给他一点控制感。