28, 安全兜底：涉及钱时，必须考虑防刷、限量和防重

1， 开放平台资源的使用需要考虑防刷

短信验证码这种开放接口，程序逻辑内需要有防刷逻辑。

第一种方式，只有固定的请求头才能发送验证码。
也就是说，我们通过请求头中网页或App客户端传给服务端的一些额外参数，来判断请求是不是App发起的。其实，这种方式“防君子不防小
人”。比如，判断是否存在浏览器或手机型号、设备分辨率请求头。对于那些使用爬虫来抓取短信接口地址的程序来说，往往只能抓取到URL，而难
以分析出请求发送短信还需要的额外请求头，可以看作第一道基本防御。

第二种方式，只有先到过注册页面才能发送验证码。
对于普通用户来说，不管是通过App注册还是H5页面注册，一定是先进入注册页面才能看到发送验证码按钮，再点击发送。我们可以在页面或
界面打开时请求固定的前置接口，为这个设备开启允许发送验证码的窗口，之后的请求发送验证码才是有效请求。
这种方式可以防御直接绕开固定流程，通过接口直接调用的发送验证码请求，并不会干扰普通用户。

第三种方式，控制相同手机号的发送次数和发送频次。
除非是短信无法收到，否则用户不太会请求了验证码后不完成注册流程，再重新请求。因此，我们可以限制同一手机号每天的最大请求次数。
验证码的到达需要时间，太短的发送间隔没有意义，所以我们还可以控制发送的最短间隔。比如，我们可以控制相同手机号一天只能发送10次
验证码，最短发送间隔1分钟。

第四种方式，增加前置图形验证码。
短信轰炸平台一般会收集很多免费短信接口，一个接口只会给一个用户发一次短信，所以控制相同手机号发送次数和间隔的方式不够有效。这
时，我们可以考虑对用户体验稍微有影响，但也是最有效的方式作为保底，即将弹出图形验证码作为前置。

真实钱的进出操作要额外小心，做好防重处理。不能凭空去操作用户的账户，每次操作以真实的订单作为依据，通过业务订单号实现全链路的幂等控制。