Golang错误处理与限流策略_处理Too Many Requests错误

遇到429应优先解析retry-after头（秒数或时间戳），未提供时采用指数退避（上限2s）；推荐预设rate.limiter主动限流，复用实例并合理配置maxidleconnsperhost防连接滥用。

go http 客户端遇到 429 Too Many Requests 怎么办

直接重试大概率失败，必须结合服务端返回的 Retry-After 响应头或指数退避逻辑。硬写 time.Sleep(1 * time.Second) 会拖慢整体吞吐，还可能被进一步限流。

• 先检查响应状态码是否为 429，别只看 err != nil —— 很多 HTTP 错误（比如 404、500）都走 resp.StatusCode 而非 err
• 优先读取 resp.Header.Get("Retry-After")：值可能是秒数（如 "60"）或 HTTP 时间戳（如 "Wed, 21 Oct 2024 07:28:00 GMT"），需分别解析
• 没拿到 Retry-After 时，用简单指数退避：第一次等 100 * time.Millisecond，第二次 200ms，第三次 400ms……上限建议设为 2 * time.Second，避免卡死

用 golang.org/x/time/rate 做客户端主动限流

比等 429 再处理更靠谱——提前把请求压在服务端能接受的节奏里。但注意它只控制“发出请求”的速率，不处理网络错误或响应延迟。

• rate.NewLimiter(rate.Limit(10), 1) 表示每秒最多 10 个请求，初始可突增 1 个；如果想允许短时爆发（比如启动时批量拉取），把第二个参数调大（如 5）
• 调用 limiter.Wait(ctx) 阻塞等待配额，比手动 time.Sleep 更准；若 ctx 已取消或超时，它会直接返回 Error，不用额外判空
• 别在每个 HTTP 请求前 new 一个 limiter——全局复用一个实例；并发高时，多个 goroutine 共享同一个 limiter 是安全的

服务端返回 429 但没带 Retry-After 头？

常见于自研网关或旧版 API，这时候不能瞎猜等待时间，得靠 fallback 策略兜底。

• 记录该 endpoint 的最近几次 429 响应耗时，用移动平均估算“实际恢复时间”，比固定值更稳
• 对关键接口，可加一层内存缓存（比如 map[String]time.Time）标记“某路径刚被限流过”，后续请求自动延迟 500ms 再发，避免雪崩
• 别忽略 Content-Length 或响应体里的提示信息——有些服务会在 body 里写 {"error": "rate limit exceeded", "reset_in_seconds": 30}，得解出来用

为什么 http.Transport.MaxIdleConnsPerHost 会影响限流效果

它不直接参与限流，但配置不当会让限流形同虚设：连接复用太多，请求看似被 rate.Limiter 拦了，实际 TCP 连接还在疯狂复用旧连接打过去。

立即学习“go语言免费学习笔记（深入）”；

• 默认值是 0（即不限），在高并发场景下容易撑爆服务端连接数，触发更激进的限流甚至连接拒绝
• 建议设为和 rate.Limit 接近的值，比如每秒限 20 请求，就设 MaxIdleConnsPerHost: 20，再配合 IdleConnTimeout: 30 * time.Second
• 如果用了自定义 http.Client，务必把 transport 显式赋给 client，否则改了也白改

真正麻烦的是混合场景：服务端限流策略不统一（有的靠 header，有的靠 body，有的只丢包），再加上客户端多个模块各自建 client、各自搞 limiter。这种时候，光靠单点修复没用，得从请求入口统一封装一层带上下文感知的限流中间件。