429 的三种成因：限流、额度与上游排队

429 表示请求被拒绝，但它背后的原因至少有三类，混在一起处理会导致重试策略失准。

第一类是速率限流，也就是单位时间请求数或 token 数超过配额。这类 429 通常带有 Retry-After 或 x-ratelimit-* 系列响应头，数值明确。处理方式是按响应头退避，不要用固定间隔硬重试，固定间隔在并发场景下会形成同步风暴。

第二类是额度耗尽。部分中转把余额不足也映射成 429，此时响应体里往往写着 quota 或 balance 关键词。这类错误重试没有意义，只会烧掉更多调用次数，应当直接告警并暂停发送。

第三类是上游排队。中转站的上游账号池容量有限，高峰期会把请求挂起后拒绝。表现为同一 Key 在低峰期完全正常，高峰期持续 429，且没有明确的重试建议。这种情况需要业务侧做队列削峰，而不是无限重试。

工程实现上建议把 429 分成可重试与不可重试两类：带 Retry-After 且响应体不含余额关键词的，进入指数退避队列；其余直接失败并记录上下文。同时给每个 Key 维护一个滑动窗口，统计最近一分钟的成功率，低于阈值时自动降级到备用线路。

另外一个细节是并发连接数。很多站点限制的是并发而不是 QPS，此时把请求压进连接池反而更稳。上线前用逐步加压的方式找到拐点，比事后猜测限流阈值更有效。

补充一个观测手段：在网关侧按分钟统计 429 数量与成功请求数的比值，画出曲线。曲线呈锯齿状（周期性冲高后回落）说明是速率限流；持续平顶说明是配额耗尽；只在整点前后冲高，往往是上游账号池切换或计费刷新造成的瞬时不可用。三种形态对应三种处理，先看图再改代码。