time.Ticker 不适合精确限流，因其仅按时间触发而忽略请求到达节奏，导致突发流量漏放；应改用 rate.Limiter 实现每 IP 独立、带突发容忍的实时判断，并在分布式场景下结合 Redis 粗粒度窗口与本地细粒度控制。
为什么 time.Ticker 不适合做精确限流
直接用 time.Ticker 控制每秒请求数，看似简单，但会漏掉突发流量的拦截——它只管“时间到了没”，不管“这秒已经来了多少个请求”。比如设定 QPS=10，但第 1 秒前 100ms 就涌入 12 个请求，time.Ticker 会在 1s 后才触发下一次检查，中间这 12 个请求全被放行，实际已超限。
真正可控的方式是：每个请求进来时立刻判断是否该拒绝。推荐用滑动窗口或令牌桶，而 Go 生态里最轻量、无依赖的方案是基于 golang.org/x/time/rate 的 rate.Limiter。
用 rate.Limiter 实现 per-IP 精确限流
默认的 rate.Limiter 是全局共享的，要实现按客户端 IP 限流，必须为每个 IP 维护独立实例。不能直接 map[string]*rate.Limiter 并长期持有——IP 太多会内存泄漏；也不能每次请求都新建——性能差且失去限流意义。
实用做法是用带过期的缓存（如 sync.Map + 时间戳标记）或更稳妥的 LRU 缓存（如 github.com/hashicorp/golang-lru/v2）。下面是一个基于 sync.Map 的简明实现：
立即学习“go语言免费学习笔记（深入）”；
var ipLimiters sync.Map // map[string]*rate.Limiter
func getLimiter(ip string) *rate.Limiter {
if lim, ok := ipLimiters.Load(ip); ok {
return lim.(*rate.Limiter)
}
// 每 IP 最大 10 QPS，允许最多 5 个请求瞬时突增（burst=5）
lim := rate.NewLimiter(10, 5)
ipLimiters.Store(ip, lim)
return lim
}
func limitMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ip := getClientIP(r)
lim := getLimiter(ip)
if !lim.Allow() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
-
rate.NewLimiter(10, 5)表示平均 10 QPS，最多允许 5 个请求“欠账”（即突发时可先透支） -
lim.Allow()是非阻塞判断，返回true表示放行，false表示应拒绝 -
getClientIP需从X-Forwarded-For或r.RemoteAddr安全提取，注意代理场景下的伪造风险
当需要分布式限流时，别硬刚 Redis Lua
单机 rate.Limiter 在多实例部署下完全失效——每个节点各自计数，总流量轻松翻倍超限。此时必须引入中心化存储。但直接在每次请求里跑 Redis Lua 脚本（如 INCR + EXPIRE 组合）容易因网络延迟或 Redis 拥塞拖慢整个 API。
更平衡的做法是：用 Redis 做粗粒度窗口（如 1 分钟窗口），再配合本地 rate.Limiter 做细粒度平滑（如每秒内均匀放行）。这样既降低 Redis 压力，又避免突刺打穿阈值。
关键点：
- Redis key 设计建议含服务名+路径+IP，例如
api:login:192.168.1.100:20240520T14（按小时分片） - 避免用
INCR后再EXPIRE—— 这两步不原子，可能 key 永久存在。改用SET key 1 EX 3600 NX初始化，再用 Lua 做原子自增+过期判断 - 如果业务能接受分钟级误差，直接用 Redis 的
INCR+EXPIRE（带NX参数）足够，不必上复杂脚本
测试限流逻辑时，别只靠 curl -v 手点
手动发请求看不出限流是否生效，尤其滑动窗口类逻辑。必须用并发压测验证行为一致性。
一个最小可用的验证脚本（Go 写）：
func TestRateLimit(t *testing.T) {
// 启动测试服务，注册 limitMiddleware
ts := httptest.NewServer(limitMiddleware(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
})))
defer ts.Close()
var wg sync.WaitGroup
success, fail := int64(0), int64(0)
for i := 0; i < 20; i++ { // 并发 20 协程
wg.Add(1)
go func() {
defer wg.Done()
resp, _ := http.Get(ts.URL)
if resp.StatusCode == http.StatusOK {
atomic.AddInt64(&success, 1)
} else if resp.StatusCode == http.StatusTooManyRequests {
atomic.AddInt64(&fail, 1)
}
}()
}
wg.Wait()
// 假设 limiter 是 10 QPS，20 请求在瞬间发出，预期 fail ≥ 10
if fail < 10 {
t.Errorf("expected at least 10 failures, got %d", fail)
}
}
真实环境中，还要关注 rate.Limiter 的 Wait 方法（会阻塞）和 Reserve（可提前预判并 Sleep）的区别——API 场景几乎总是用 Allow 或 Reserve，避免阻塞 goroutine。
最后提醒：限流阈值不是拍脑袋定的。上线前务必用真实链路压测，观察下游 DB、缓存、第三方接口的水位，否则限流可能把压力转移到更脆弱的环节。
