429 + Retry-After: 58攻击流量被服务端挡在登录逻辑外；客户端等到窗口结束再试，正常用户和监控有独立配额。
数据与服务 · 账号与安全
限流Rate Limit
限流按 key 在时间窗口内设请求上限：登录常组合 IP + 账号；超限回 429 + Retry-After，让客户端退避等待而不是猛重试。
在第六次登录请求前关上门禁
同一 IP 加账号的登录请求在 60 秒内最多放行 5 次。亲手填满窗口、第 6 次触发 429，再按 Retry-After 恢复；结果直接长在门禁槽位和响应对象上。
账号防刷 · POST /login
让同一个登录攻击在第六次前停在门外
限流 key
/login · ip=10.0.0.4 · account=aliceIP + 账号：既挡同 IP 撞库，也避免只按 IP 误伤整层办公网。60 秒窗口0 / 5
还可放行 5 次
本次响应 · 原因 · 下一步200 OK
原因：请求写入同一个 key 的窗口计数；下一步：连续发送到第六次，观察它如何被门禁拒绝。
键盘：Tab 定位按钮，Enter 或空格触发。连续发送 6 次；第 6 次看到 429 后，只能等待窗口结束再试，而不是再猛点发送。
门禁刚刚证明的三条规则
限流不是一条“慢一点”的提示，而是一条可计算、可恢复的服务端规则。
- 限流 = key + 窗口 + 上限。这里的 key 组合路由、IP 和账号；服务端只在 60 秒窗口内为同一个 key 计数。
- 超限响应是 429 + Retry-After。第六次被拒后不进入登录逻辑，也不再消耗配额；客户端读取等待时间、退避后再试，不能忙循环。
- key 决定谁会被一起计算。登录常组合 IP 和账号：IP 桶抵挡同来源撞库，账号桶抵挡换 IP 猜同一密码；健康检查要走白名单或独立配额。
什么时候用：先看接口会不会被刷或拖垮
把限流放在成本高、可滥用的入口，而不是用它代替鉴权。
- 优先覆盖：登录、注册、找回密码、验证码、搜索、导出和计费接口；它们容易被撞库、轰炸或放大成本。
- 按对象配额：终端用户、API key、付费等级和内部健康检查应有不同桶；不要让全站共用一个桶。
- 不要替代鉴权：限流只处理“太快”，没有权限的请求仍应在鉴权层拒绝。
从请求到恢复：最短实现链
以 Redis 固定窗口为起点，先把响应、观察和误伤边界都接上。
- 在网关或中间件计算
route + IP + account等 key，并用 RedisINCR计数。 - 首次写入时设置
EXPIRE；计数超过上限立即返回429、Retry-After和可读消息。 - 客户端按 Retry-After 指数退避，写操作带幂等键；记录允许/拒绝次数和 key 分布，识别误伤与重试风暴。
同一登录目标：防撞库，还是放大重试风暴
只改 key 和恢复响应，用户后果就完全不同。
setInterval(retryLogin, 200)一个热门接口会拖垮所有用户；没有等待指示时，客户端不断重试，把一次超限放大成流量风暴。
快速自测
登录接口按 IP + 账号限流已返回 429 和 Retry-After: 45；客户端下一步该做什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。
用到这个知识点的案例
看看真实的项目蓝图里，限流是怎么被用上的。