遇到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。这种时候，光靠单点修复没用，得从请求入口统一封装一层带上下文感知的限流中间件。
