限流不能仅用time.Sleep，因其阻塞goroutine导致雪崩；应让超限请求立即失败或排队。推荐使用golang.org/x/time/rate包，它基于令牌桶、无锁高效，支持突发流量控制。
限流为什么不能只靠 time.Sleep
直接在 HTTP handler 里用 time.Sleep 拖慢响应，看似“限了速”，实则阻塞 goroutine，浪费调度资源。当并发请求突增时，大量 goroutine 挂起，内存和上下文切换开销飙升，服务反而更容易雪崩。
真正可控的限流，得让超出速率的请求**立刻失败或排队**，而不是无差别拖住所有处理流程。
用 time.Ticker 实现固定窗口计数器（简单但有边界问题）
适合低精度、开发环境快速验证。核心是维护一个计数器 + 重置时间戳，每次请求检查是否在当前窗口内、是否超限。
func NewFixedWindowLimiter(max int, window time.Duration) http.Handler {
var mu sync.RWMutex
var count int
var lastReset time.Time
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
mu.Lock()
now := time.Now()
if now.After(lastReset.Add(window)) {
count = 0
lastReset = now
}
if count >= max {
mu.Unlock()
http.Error(w, "rate limit exceeded", http.StatusTooManyRequests)
return
}
count++
mu.Unlock()
// 继续处理请求
next.ServeHTTP(w, r)
})
}
- 窗口边界不平滑：比如窗口是 1 分钟，但用户在 59 秒和 1 秒连续发起请求，可能被算作两次窗口内的合法请求
- 没考虑并发安全细节？
count和lastReset必须用sync.RWMutex保护，否则竞态导致漏放行或误拦截 - 不适合高 QPS 场景：每请求都加锁，锁争用会成为瓶颈
用 time.Now().Sub() + 滑动窗口日志（精确但内存敏感）
记录每个请求的时间戳，每次请求时剔除窗口外的旧记录，再判断剩余数量。精度高，但需注意日志膨胀。
type SlidingWindowLimiter struct {
mu sync.RWMutex
logs []time.Time
max int
window time.Duration
}
func (l *SlidingWindowLimiter) Allow() bool {
now := time.Now()
l.mu.Lock()
defer l.mu.Unlock()
// 剔除过期时间戳
cutoff := now.Add(-l.window)
i := 0
for _, t := range l.logs {
if t.After(cutoff) {
l.logs[i] = t
i++
}
}
l.logs = l.logs[:i]
if len(l.logs) >= l.max {
return false
}
l.logs = append(l.logs, now)
return true
}
- 内存增长不可控：如果
max是 1000，但实际每秒 500 请求，logs切片可能长期维持在几百个元素，没问题；但如果突发 10 万请求，瞬间分配并保留 10 万个time.Time，GC 压力明显 - 没做预分配？建议初始化时用
make([]time.Time, 0, l.max*2)减少扩容次数 - 纯内存方案，进程重启即清空——生产环境需搭配 Redis 等外部存储才可靠
推荐组合：golang.org/x/time/rate + 中间件封装
标准库扩展包 rate.Limiter 底层用原子操作 + time.Now() 计算令牌生成，无锁、低开销、支持预热和突发流量控制，是生产首选。
立即学习“go语言免费学习笔记（深入）”；
import "golang.org/x/time/rate"
var limiter = rate.NewLimiter(rate.Limit(100), 10) // 100 QPS，初始 10 令牌
func RateLimitMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
-
rate.Limit(100)表示每秒补充 100 令牌，不是“最多 100 并发”——它允许短时突发（取决于桶容量），更贴合真实流量特征 - 别漏掉错误处理：若使用
WaitN(ctx, n)，必须检查 ctx 是否超时或取消，否则可能永久阻塞 - 每个路由/用户需要独立限流？那就不能共用一个
limiter实例，得按 key（如 IP 或 user ID）做 map 缓存，并配 TTL 清理，否则内存泄漏
真正难的从来不是“怎么写限流代码”，而是决定每个接口该用哪种策略、多少阈值、是否区分用户等级、失败后要不要降级返回缓存——这些得看监控数据，而不是凭空拍参数。
