429 是什么
429 Too Many Requests 表示客户端在给定时间内发送了过多请求，被限流策略拒绝。它不属于最初的规范，而是后来补充定义的，如今已经是接口与网关的标配。响应通常带上重试等待时间头，也可能附带剩余配额与重置时间等信息。收到它意味着请求是合法的、服务器也有能力处理，只是节奏太快——因此正确的应对是退避等待，而不是立刻重试。
基本信息
| 名称 | 429 Too Many Requests（见 RFC 6585 §4） |
|---|---|
| 作用 | 限流拒绝，请求合法性没有问题 |
| 关键头部 | 重试等待时间头；配额类的信息头属于约定俗成 |
| 常见触发点 | 网关层、应用层、第三方接口层，可能多层叠加 |
| 正确应对 | 按提示退避并加抖动，必要时降低并发 |
典型使用场景
- 接口保护：防止单个调用方占满资源，保护其他用户
- 爬虫与采集：站点主动限制抓取频率，提示抓取方降速
- 登录与短信：限制单位时间内的尝试次数，对抗撞库
- 第三方配额：对方接口按套餐限定调用次数
- 批量任务：任务开始前先看剩余配额，避免跑到一半被拦住
尊重退避提示
尊重退避提示
curl -si https://api.example.com/search # 先看状态行与配额相关头部
# 从响应头里取出等待秒数，再按它休眠，不要自己凭空猜一个值
sleep 12 && curl -s https://api.example.com/search
# 批量任务应控制并发并按批次间隔执行，比失败后重试更省事限流可能出现在哪一层
| 位置 | 特征 | 处置方向 |
|---|---|---|
| 边缘网关 | 所有接口统一被拦，与业务无关 | 调整调用方节奏或申请提升额度 |
| 应用层 | 只有部分接口被拦，与业务规则相关 | 核对接口文档给出的配额 |
| 第三方接口 | 调用对方接口时收到 | 按对方文档退避，并做本地配额预判 |
| 多层叠加 | 同时存在多种阈值 | 分别核对两侧配置，不能只看一处 |
排查要点
- 先看响应头里的等待秒数是否被真正遵守，很多脚本忽略了它
- 统计被限流请求的时间分布，判断是突增还是持续超配额
- 多层限流叠加时逐层核对阈值，只调一层往往不解决问题
收到限流继续硬重试会加重限流甚至导致来源被封禁，故障从「慢」变成「完全不可用」。正确做法是按提示等待并叠加随机抖动，避免所有客户端在同一时刻同时重试。
配额类信息头并不属于强制规范，各家的命名与语义有差异。接入第三方接口时以对方的文档为准，不要把某一家厂商的习惯当成通用标准。