Go中限制网络请求速率的核心是用rate.Limiter控制请求发出节奏，需复用限流器、优先调用Wait(ctx)、按租户/IP多实例隔离、burst不宜过大、定期清理过期key，并可集成到RoundTripper层实现零侵入。
Go 中限制网络请求速率，核心不是“拦住请求”，而是“控制发出去的节奏”——用 rate.Limiter 在每次调用前卡住时间点，让平均速率落在预期范围内。它不改 HTTP 状态码逻辑，也不依赖中间件生命周期，直接作用于请求发起瞬间。
用 rate.Limiter 控制单次 HTTP 请求频率
这是最常用、最轻量的方案，适用于客户端主动调用下游服务（如调用支付网关、短信平台）的场景。关键在于：限流器必须复用，不能每次新建。
- 错误写法：
limiter := rate.NewLimiter(10, 5)放在 handler 或方法内部 → 每次都新实例，完全无效 - 正确做法：全局变量或结构体字段持有，例如
client.rateLimiter，初始化一次长期复用 - 调用时优先用
limiter.Wait(ctx)（带超时），而非Allow()；否则客户端断连后 goroutine 可能永久阻塞 - 若下游返回
429，建议本地临时降级（如把 QPS 减半），而不是继续硬等令牌
按租户/IP/服务名做多实例限流
当多个上游共用一个 HTTP client（比如 SaaS 平台中不同客户调用同一通知服务），必须隔离限流上下文，否则 A 客户刷爆会拖垮 B 客户。
- 用
sync.Map缓存 key →*rate.Limiter映射，key 可以是r.Header.Get("X-Tenant-ID")或r.RemoteAddr - burst 值不宜过大（如超过 100），否则突发流量仍可能打满连接池或下游 CPU
- 不清理过期 key？内存会缓慢增长 —— 推荐搭配
time.AfterFunc或定期扫描，删除 30 分钟无访问的 limiter - 注意：
sync.Map的LoadOrStore是线程安全的，但不要在 Load 后再手动 New 再 Store，应确保原子性
集成到 http.Client 的 RoundTripper 层
把限流下沉到 transport 层，业务代码零侵入，适合 SDK 或基础库封装。难点在于如何把“当前请求所属的限流维度”传递进去。
立即学习“go语言免费学习笔记（深入）”；
- 自定义
RoundTripper，在RoundTrip(req)开头读取req.Context().Value("rate_key")获取租户标识 - 从预置 map 中查出对应
*rate.Limiter，调用Wait(req.Context()) - 务必传入带超时的 context（如
context.WithTimeout(req.Context(), 200*time.Millisecond)），避免因令牌不足导致整个请求 hang 死 - 如果下游支持
Retry-After头，可解析后设置下次重试延迟，比盲等更合理
真正难的不是写对那几行 limiter.Wait()，而是想清楚“谁该被限”“被限到什么程度”“限不住时往哪退”。比如 burst 设成 5 还是 50，差的不只是数字，是系统在突发流量下的呼吸节奏；而跨实例限流不接 Redis，单机 limiter 再准也只是一厢情愿。
