API 被刷是接口型业务的常见攻击面：验证码接口被批量调用、短信接口被恶意触发、查询接口被竞对爬取。损失直接体现在账单与服务质量上。防护设计在三道控制上展开。
## 适用场景与影响
被刷的接口有几类共性：有经济成本，短信与通知类接口每次调用都产生费用；有数据价值，查询类接口的内容可被批量收割；有资源占用，高频调用把 CPU 与带宽拖垮，正常用户跟着受害。判断被刷的信号：调用量曲线异常抬升、单一来源的高频请求、参数特征高度雷同的批量调用。
## 三道控制的设计
第一道限流：按来源维度设置调用上限，超过阈值的请求直接拒绝或排队。粒度分层设计：单地址的秒级上限、单账号的分钟级上限、全局的弹性上限，三层各防一类滥用。第二道签名：请求参数加时间戳与密钥生成签名，服务端校验并限制时间窗口防重放。签名让脚本不能简单重放抓包，攻击成本抬高一截。第三道业务频控：在业务逻辑层判断行为合理性，同一手机号的短信间隔、同一账号的查询节奏、异常时段的调用模式，超出合理边界的走验证码或人工确认。
## 验证方法
上线前用压测工具模拟异常模式：固定来源高频调用应被限流层拦截，重放的旧签名应被时间窗口拒绝，业务频控在触发阈值后返回明确的处理指引。上线后观察拦截日志的分布，误伤率与漏过率双向核对，规则参数按观察数据调整。
## 注意事项
限流阈值要给正常波动留余量，促销与高峰场景提前调参，避免保护机制变成可用性事故。拦截响应里不暴露过多细节，规则特征被摸清后绕过成本会降低。顺云控制台的带宽与连接监控可以及早发现异常调用曲线，应用侧的三道控制按业务形态调参，两层配合覆盖大多数刷接口场景。