写短信验证码接口没做限流，被脚本一秒刷几百次，扣了我三百块短信费

之前做用户注册功能，写了个短信验证码接口，用户填手机号，点获取验证码，我就调短信服务商接口发验证码，当时图省事，根本没做任何限制，觉得正常人注册一天能收几次验证码，能有多少。结果上线第三天，我收到短信服务商的消费提醒，一夜之间扣了我三百多块短信费，我当时人都傻了，赶紧登后台看接口日志，发现有人写脚本，一秒钟发两百个请求，全是不同的手机号，一晚上发了五千条短信，全扣的我账户里的钱。 我当时立刻把接口关了，查日志，发现脚本从半夜两点刷到早上五点，我根本没开监控告警，等发现的时候钱已经扣完了。后来我加了个最简单的限流：同一个IP，一分钟最多请求5次短信接口，同一个手机号，一小时最多发3次，超过次数直接返回“请求太频繁”，就这么几行简单的判断，从那之后再也没被人刷过。 很多新手写接口，尤其是涉及到付费服务的：短信、邮件、云存储，总觉得没人会专门来刷我，其实网上有公开的脚本，自动扫全网的这种裸露接口，找到就自动刷，能薅多少羊毛是多少，根本不是针对你。你接口不做限流，等于把自己的短信账户白送给别人刷，我那三百块的学费，买了个教训：只要接口会产生费用，必须从一开始就加限流，哪怕是最简单的计数限制。 现在我写任何对外接口，第一件事就是加基础限流：单IP一分钟请求次数限制，敏感操作比如发短信、发邮件，再加频率限制，超过就拦。就这么简单的几行代码，能挡住90%的恶意脚本，比你事后找服务商申诉退费靠谱多了。我当时找短信服务商要退费，人家说接口是你自己开放的，没做防护，钱已经扣了，退不了，我只能吃个哑巴亏。 新手写代码总觉得这些防护是多余的，等真被人把钱刷没了，才后悔当初没花十分钟写个限流逻辑，真的别犯我这种错。