一个做会员商城的客户早上被账单吓醒：短信平台显示昨晚发出两万多条验证码短信，可当天注册用户不到一百个。排查日志才发现，注册接口被人用脚本批量调用，同一个IP一秒请求了三十次。一晚上四千多块短信费打了水漂，这种事在后端系统开发里特别典型，防线不是不能建，是很多项目压根没建。
防刷要一层一层设卡
第一道闸是验证码前置：发短信之前先过一道图形验证码或滑块，脚本的自动化流程就被拦下大半。第二道是频率限制，分两个维度同时做：同一个手机号一天最多收十条，间隔一分钟起步；同一个IP一小时最多请求二十次，超出直接拒绝。第三道才是接口限流，整个接口设个总闸，每秒超过多少请求就排队或拒绝，防止洪水冲垮服务器。三层下来，脚本的成本高到不值得动手，刷子自然就走了。
限流不用高深算法
- 最简单的计数器就够用：手机号做键，一分钟内计数超了就拒绝，Redis两条命令的事；
- 拒绝要干脆，返回明确的错误提示，别让请求挂着等，占着资源；
- 告警必须配上：短信发送量一小时超过五百条就通知管理员，当晚就能止损，而不是第二天看账单才发现。
那位客户的系统补救只花了一天：验证码前置加双重频率限制加量级告警，之后再没被刷过。成本不到当初短信损失的十分之一，防刷这类活，做在事前和做在事后，价格差出一个数量级，这也是后端系统开发报价里最值得提前谈的一条。
还要提醒一句容易被忽略的地方：内部接口别裸奔。有些团队把导出、查询这类接口直接挂在公网上，连登录校验都没有，被扫到就是批量拖数据。不对外提供能力的接口，要么收进内网，要么加上鉴权和访问限制，这是底线，不是可选项。防刷的本质和防盗一样，不追求绝对拦住，而是让动手的成本高过收益，刷子自然就散了。
签约时就该问的事
验收系统时拿几个具体问题问开发方：发短信接口有没有频率限制，限的是多少？验证码前置有没有？发送量异常谁在什么时候知道？这三个问题都答得上来，防线基本在；支支吾吾的，就要留个心眼。
两条建议：涉及短信、支付、营销发券的接口，立项时就把防刷要求写进需求文档，验收时拿工具实测连点二十次看反应；已经在线上跑的系统，让比格网络这类团队做一次接口暴露面排查，把没设防的口子找出来补上，花的钱肯定比下一次被刷少。
