最常用轻量HTTP限流方式是golang.org/x/time/rate.Limiter，基于令牌桶算法、线程安全；需服务启动时复用实例，按IP/用户/路径等粒度限流，配合sync.Map实现per-IP限流并注意过期清理，返回429时应设Retry-After等标准响应头，高并发下需关注Reserve()带来的GC和锁竞争问题。
golang.org/x/time/rate 实现 HTTP 请求限流限流最常用、最轻量的方式就是用官方维护的 rate.Limiter。它基于令牌桶算法，线程安全，适合在 HTTP handler 中直接使用。
关键点是：不要为每个请求新建 rate.Limiter，而应在服务启动时初始化并复用；限流粒度按 IP、用户 ID 或路由路径决定，不能只靠全局单例。
rate.NewLimiter(rate.Limit(10), 5) 表示最大每秒 10 个请求，初始桶容量为 5（允许短时突发）limiter.Allow() 判断是否放行，返回 true 表示通过；更推荐用 limiter.Wait(ctx)，它会自动阻塞或超时，避免忙等r.RemoteAddr 提取客户端真实 IP（注意 X-Forwarded-For 可伪造，生产环境应结合可信代理列表校验）func rateLimitedHandler(limiter *rate.Limiter) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("OK"))
}
}
单纯用一个全局限流器无法区分不同用户，容易误伤。常见做法是用 sync.Map 按 IP 维护独立的 *rate.Limiter，但要注意内存泄漏和过期清理。
问题在于：长期存活的 rate.Limiter 实例不会自动销毁，若不做淘汰，map 会无限增长。不建议用 time.Now().Sub() 手动遍历清理——性能差且易出错。
立即学习“go语言免费学习笔记（深入）”；
sync.Map 存储 map[string]*rate.Limiter，key 是清洗后的 IP 字符串LoadOrStore 获取对应限流器，避免重复创建
改用带 TTL 的库如 github.com/patrickmn/go-cache
返回 429 Too Many Requests 时，光给状态码不够。客户端需要知道“什么时候能再试”，否则可能盲目重试加剧压力。
标准做法是设置 Retry-After 响应头，值可以是秒数或 HTTP-date。但 rate.Limiter 本身不暴露下次可用时间，得自己算。
limiter.Reserve() 得到 *rate.Reservation，再用 reservation.Delay() 获取等待时长Delay() 返回 0，说明可立即执行，仍建议设 Retry-After: 0 保持语义清晰time.Now().Add(delay).Format(time.RFC1123)），因客户端时钟可能不准；优先用秒数X-RateLimit-Limit、X-RateLimit-Remaining 等 header，方便前端调试func withRateLimitHeader(limiter *rate.Limiter) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
res := limiter.Reserve()
if !res.OK() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
if delay := res.Delay(); delay > 0 {
w.Header().Set("Retry-After", strconv.FormatInt(int64(delay.Seconds()), 10))
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("OK"))
}
}
rate.Limiter 的性能隐患rate.Limiter 单实例在万级 QPS 下基本无压力，但一旦引入 per-IP map + Reserve() 调用链，CPU 和 GC 压力会上升明显——尤其是频繁调用 Reserve() 创建临时对象。
真正卡点往往不在算法本身，而在锁竞争和内存分配。比如用 sync.RWMutex 包裹 map 访问，在热点 IP 频繁请求时会成为瓶颈。
runtime.ReadMemStats 中的 PauseTotalNs 和 NumGC，若 GC 频繁，很可能是 Reserve() 或日志打印导致的短期对象暴增