API刷请求防护按业务成本选限流策略，关键接口先分级

API接口遭受刷请求时的限流与防护方案，首先要回答的不是“每秒允许多少次”，而是哪些请求超量后最贵、最影响业务。读取公开数据和发送验证码，对数据库、第三方费用与用户体验的影响完全不同；若共用一个阈值，轻则误伤正常用户，重则让高成本接口继续消耗资源。

先按业务损失分级，再按接口特性选限流方式。限流负责控制进入系统的请求量，鉴权、缓存、熔断和监控则补足它处理不了的问题。

按故障成本给接口分级

一级：关键且高成本。例如登录验证、验证码发送、订单提交或触发付费第三方调用的接口。重点是保护账号、资金、外部调用额度和核心依赖，应采用较严格的用户、账号或业务对象维度配额，并设置并发上限。
二级：重要读写接口。例如个人资料更新、搜索或订单查询。结合用户身份、访问频率和后端承载能力限流；读请求可优先利用缓存，写请求则需避免重复提交造成副作用。
三级：可降级的非核心接口。例如非关键统计或辅助信息。可以较早返回缓存结果、延迟处理或拒绝服务，避免挤占核心接口资源。

分级时记录单次请求的计算、数据库和外部服务成本，以及被限制后的业务影响。不能确认成本的接口先观察调用量、错误率和延迟，再通过压测或小流量调整，不要凭感觉设置固定阈值。

策略	适用情况	优势与限制
固定窗口	按分钟或小时统计配额	实现直观、易解释；窗口边界可能出现短时突发，适合容忍一定波动的场景。
令牌桶	允许短暂突发，但需控制长期平均速率	可同时设置补充速率和桶容量；需要处理分布式状态，配置不当仍会放大突发。
并发限制	单次请求耗时长、占用连接或工作线程	直接约束同时处理的任务；高延迟期间可能提前触发，应结合超时和队列监测。

例如，验证码发送通常还要按账号、手机号或业务对象控制频次，并防止匿名请求造成费用；商品目录读取则可组合缓存与令牌桶，减少突发访问对数据库的压力。IP限流可作为补充，但共享网络下多个正常用户可能共用出口地址，不能把它当作唯一身份依据。

盘点接口。列出路径、方法、身份要求、依赖服务、平均与高峰调用量，并标注故障后果和是否可以降级。
选限流维度。按风险使用账号、API密钥、租户或资源标识；匿名流量可辅以IP维度。避免只按一个维度判定，防止共享出口误伤或更换来源绕过规则。
先监控再拦截。在 API 网关或服务入口记录限流命中数、请求延迟、后端错误率和拒绝原因。先观察实际流量，再用灰度规则确认正常业务不会频繁触发。
明确超限行为。可返回 HTTP 429，并在适用时提供 Retry-After；对可降级的读取请求返回缓存，对关键写操作则清楚提示稍后重试，避免客户端无间隔重试。
验证失败场景。测试突发请求、规则服务不可用、多个实例同时计数及正常流量高峰。根据资源瓶颈调整配额、并发上限或缓存策略，并为规则设置负责人和回滚方式。

如果请求没有经过可靠身份校验，攻击者可能不断更换来源；若系统本身存在昂贵查询，单纯放宽配额仍会造成资源耗尽。因此应组合使用鉴权、参数校验、缓存、超时、熔断以及网关或 CDN 的基础防护。共享限流状态还要考虑多实例部署：仅在单台服务进程内计数，无法代表整个集群的总量。

API接口遭受刷请求时的限流与防护方案，最终要按业务成本持续校准：关键接口优先保可用和可控，低风险接口优先减少实现与运维负担。每次调整都检查拒绝请求、正常用户错误率和后端资源变化，才能避免“挡住了流量，却挡住了业务”。

从真实调用数据和后端容量出发，结合高峰流量、请求成本与业务可接受的失败率，通过观察、压测和小流量验证逐步调整。

通常不够。共享网络会让正常用户共用出口地址，来源也可能变化；应按接口风险结合账号、租户或资源标识，并将 IP 作为辅助信号。

可返回 HTTP 429，并说明何时可重试；客户端应采用退避重试，避免立即重复发送。写操作还要考虑幂等处理。

网关适合统一入口保护和基础配额；应用内更了解业务身份与操作成本。关键接口可组合使用，并明确两处规则的优先级。