最常用轻量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)，它会自动阻塞或超时，避免忙等 - 若需按 IP 限流，从
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"))
}
}
基于中间件实现 per-IP 限流
单纯用一个全局限流器无法区分不同用户，容易误伤。常见做法是用 sync.Map 按 IP 维护独立的 *rate.Limiter，但要注意内存泄漏和过期清理。
问题在于：长期存活的 rate.Limiter 实例不会自动销毁，若不做淘汰，map 会无限增长。不建议用 time.Now().Sub() 手动遍历清理——性能差且易出错。
立即学习“go语言免费学习笔记（深入）”；
GitHub 项目更新追踪工具 - 自动检查多个 GitHub 项目的 Releases 和 CHANGELOG，生成更新摘要与影响分析报告。支持自动化定时任务。 如何使用 最简单的方式：直接用自然语言告诉我 你可以说 我会做 「检查 GitHub 更新」 检查最新版本 「添加 vscode」 追踪新项目 「停止追踪 xxx」 移除项目 「暂停更新检查」 暂停自动化 「给我看 openclaw 报告」 展示报告 触发词：「追踪项目更新」「检查 GitHub 更新」「项目更新报告」「设置更新提醒」
- 用
sync.Map存储map[string]*rate.Limiter，key 是清洗后的 IP 字符串 - 每次请求先
LoadOrStore获取对应限流器，避免重复创建 - 配合后台 goroutine 定期扫描过期项（例如 30 分钟无访问的 IP），但更稳妥的做法是改用带 TTL 的库如
github.com/patrickmn/go-cache - 注意 IPv6 地址字符串长度远大于 IPv4，做 key 时建议统一规范化（如去掉前导 0、转小写）
HTTP 429 响应头与重试提示
返回 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 频繁请求时会成为瓶颈。
- 避免在 handler 中做字符串拼接、正则匹配、JSON 解析等耗时操作后再限流；应尽早拦截
- 对静态资源（/static/、/healthz）或已认证的内部服务调用，建议跳过限流逻辑
- 压测时观察
runtime.ReadMemStats中的PauseTotalNs和NumGC，若 GC 频繁，很可能是Reserve()或日志打印导致的短期对象暴增 - 极端场景可考虑用原子计数器 + 时间窗口（如每秒重置）替代令牌桶，牺牲精度换性能，但要注意时钟跳跃导致的窗口错位
