9. PHP 短信验证码防刷机制

　　1、时间限制：60 秒后才能再次发送

　　从发送验证码开始，前端(客户端)会进行一个 60 秒的倒数，在这一分钟之内，用户是无法提交多次发送信息的请求的。这种方法虽然使用得比较普遍，但是却不是非常有用，技术稍微好点的人完全可以绕过这个限制，直接发送短信验证码。

　　2、手机号限制：同一个手机号，24 小时之内不能够超过 5 条

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

　　3、短信验证码限制：30 分钟之内发送同一个验证码

　　网上还有一种方法说：30 分钟之内，所有的请求，所发送的短信验证码都是同一个验证码。第一次请求短信接口，然后缓存短信验证码结果，30 分钟之内再次请求，则直接返回缓存的内容。对于这种方式，不是很清楚短信接口商会不会对发送缓存信息收取费用，如果有兴趣可以了解了解。

　　4、前后端校验：提交 Token 参数校验

　　这种方式比较少人说到，个人觉得可以这种方法值得一试。前端(客户端)在请求发送短信的时候，同时向服务端提交一个 Token 参数，服务端对这个 Token 参数进行校验，校验通过之后，再向请求发送短信的接口向用户手机发送短信。

　　5、唯一性限制：微信产品，限制同一个微信 ID 用户的请求数量

　　如果是微信的产品的话，可以通过微信 ID 来进行识别，然后对同一个微信 ID 的用户限制，24 小时之内最多只能够发送一定量的短信。

　　6、产品流程限制：分步骤进行

　　例如注册的短信验证码使用场景，我们将注册的步骤分成 2 步，用户在输入手机号码并设置了密码之后，下一步才进入验证码的验证步骤。

　　7、图形验证码限制：图形验证通过后再请求接口

　　用户输入图形验证码并通过之后，再请求短信接口获取验证码。为了有更好的用户体验，也可以设计成：一开始不需要输入图形验证码，在操作达到一定量之后，才需要输入图形验证码。具体情况请根据具体场景来进行设计。

　　8、IP 及 Cookie 限制：限制相同的 IP/Cookie 信息最大数量

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

　　我们也应该做好短信的预警机制，即当短信的使用量达到一定量之后，向管理员发送预警信息，管理员可以立刻对短信的接口情况进行监控和防护。