Go限流不能只靠time.Sleep，因其会阻塞goroutine、无法应对突发流量、不支持并发统计且难解耦；应使用rate.Limiter令牌桶或Redis+Lua滑动窗口实现分布式限流。
Go 限流为什么不能只靠 time.Sleep
直接用 time.Sleep 模拟“匀速放行”看似简单，但实际会阻塞 goroutine、无法应对突发流量、不支持并发统计，且无法与 HTTP 中间件解耦。真正可用的限流必须基于原子计数、滑动窗口或令牌桶，并能被多个请求共享状态。
使用 golang.org/x/time/rate 实现令牌桶限流
rate.Limiter 是 Go 官方推荐的轻量级限流器，底层是令牌桶算法，线程安全，适合 HTTP 中间件场景。
- 初始化时指定每秒填充速率（
rate.Every(time.Second / 10)表示 10 QPS）和最大突发量（burst） - 每次请求调用
limiter.Wait(ctx)，阻塞直到拿到令牌；也可用limiter.Allow()做非阻塞判断 - 注意：burst 值过小会导致突发请求直接被拒，过大则削弱限流效果；建议设为 QPS 的 2–3 倍
func rateLimitMiddleware(next http.Handler) http.Handler {
limiter := rate.NewLimiter(rate.Every(time.Second/5), 10) // 5 QPS，允许最多 10 个突发
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)
})
}用 Redis + Lua 实现分布式滑动窗口限流
单机 rate.Limiter 无法跨实例共享状态。生产环境需分布式限流，滑动窗口比固定窗口更平滑，推荐用 Redis 的 ZSET + Lua 脚本保证原子性。
- 以用户 IP 或 token 为 key，将请求时间戳作为 score 存入
ZSET - Lua 脚本负责：清理过期时间戳（score window）、计算当前窗口请求数、插入新时间戳
- 避免在 Go 层做多次 Redis 往返，所有逻辑收束到一个
EVAL调用中 - 注意：Redis 时间必须与应用服务器时间同步，否则窗口计算偏移
-- lua script: sliding_window.lua
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local max_req = tonumber(ARGV[3])
<p>redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count >= max_req then
return 0
end
redis.call('ZADD', key, now, now .. ':' .. math.random(1000, 9999))
redis.call('EXPIRE', key, window + 1)
return 1HTTP 中间件里如何正确注入限流上下文
限流策略常需区分接口粒度（如 /api/pay 限 100 QPS，/api/status 限 1000 QPS），不能全局共用一个 rate.Limiter。
立即学习“go语言免费学习笔记（深入）”；
- 按路径前缀或路由名动态获取对应限流器，建议用
sync.Map缓存已初始化的*rate.Limiter - 避免在每次请求中 new Limiter —— 它不是 cheap object，且会导致 GC 压力和状态丢失
- 若用 Gin/Echo，可在路由分组上挂载不同中间件，而非在统一中间件里硬编码 if-else 判断 path
- 记录被限流的请求日志时，务必带上 key（如 IP+path）、当前计数、拒绝原因，否则排障无从下手
真正难的不是写对一段限流代码，而是决定 burst 值是否该随负载自动调整、Redis 故障时要不要降级为本地漏桶、以及哪些接口该限流哪些不该 —— 这些都得靠线上指标反馈，而不是文档里抄个数字就完事。
