用 rate.Limiter 做单机限流最稳妥，它基于令牌桶算法、线程安全、可扛突发；需复用实例、用 Wait(ctx) 避免阻塞；按用户/IP/路径限流时须用 sync.Map 缓存并定期清理过期 key；集群场景必须用 Redis+Lua 原子实现。
用 rate.Limiter 做单机限流最稳妥，别手写计数器
生产环境首选 golang.org/x/time/rate，它基于令牌桶算法，线程安全、无依赖、能扛突发流量。自己实现计数器（比如用 sync.Map + 时间戳）看似简单，但容易掉进“窗口切换突刺”陷阱——例如固定窗口在 00:59.9s 和 01:00.1s 各来 100 请求，实际一秒内就打了 200 次。
关键点：
-
rate.NewLimiter(rate.Every(100*time.Millisecond), 5)表示每 100ms 放 1 个令牌，桶容量为 5 —— 即允许最多 5 次瞬时请求，平均 QPS 是 10 - 必须复用同一个
*rate.Limiter实例，不能在 handler 函数里每次 new；否则 goroutine 竞争下限流失效 - 别用
Allow()判断后才塞 context 超时；应提前带超时的ctx传给Wait(ctx)，否则可能永久阻塞
按用户/IP/路径做差异化限流，sync.Map 缓存要配过期清理
全局一个限流器不够用，真实场景需按 X-Real-IP、X-User-ID 或路由 path 分别限流。这时得用 sync.Map 缓存每个 key 对应的 *rate.Limiter，但要注意：不清理就会内存泄漏。
常见错误：
立即学习“go语言免费学习笔记（深入）”；
- 只写
m.LoadOrStore(key, newLimiter())，没配定时清理逻辑 → key 越积越多，OOM 风险 - 用
time.AfterFunc给每个限流器设过期，但 key 失活后无法主动触发清理 → 还是涨内存
推荐做法：后台起 goroutine，定期扫描 sync.Map，对超过 5 分钟未访问的 key 调用 Delete；或者直接用带 TTL 的 LRU 库（如 github.com/hashicorp/golang-lru/v2）。
多实例部署必须上 Redis + Lua，别信两步 INCR+EXPIRE
单机 rate.Limiter 在微服务集群里完全失效。跨节点共享状态只能靠 Redis，但直接用 INCR + EXPIRE 两步走有竞态风险：INCR 成功了，EXPIRE 却失败，key 就永远卡在 Redis 里。
正确姿势是 Lua 脚本原子执行：
-- KEYS[1] 是限流 key（如 "ip:192.168.1.1"）
-- ARGV[1] 是窗口秒数，ARGV[2] 是最大请求数
local current = redis.call("INCR", KEYS[1])
if current == 1 then
redis.call("EXPIRE", KEYS[1], ARGV[1])
end
return current <= tonumber(ARGV[2])注意：
- Go 调用时用
redis.NewScript(lua)，避免每次 EVAL 计算 SHA；预加载脚本 SHA 更稳，防止 Redis 版本差异导致 EVALSHA 失败回退到慢路径 - 滑动窗口精度更高，但需用 ZSET +
ZCOUNT，比固定窗口多一次网络往返；若 P99 延迟已超 50ms，优先选固定窗口保响应速度
限流不是加个中间件就完事，漏掉监控等于没做
上线后没人看指标，等于裸奔。必须暴露 Prometheus counter，比如 http_requests_limited_total{route="/api/user", reason="per_ip"}，再配 PromQL 告警：rate(http_requests_limited_total[5m]) > 10。
还有几个硬伤常被忽略：
- 健康检查端点（如
/health）被误限 —— 中间件里要显式放行，别让它走限流逻辑 - 没打结构化日志记录被限流的 IP、path、时间戳 → 出问题时没法快速定位是攻击还是业务异常
- 限流阈值写死在代码里，无法热更新 → 至少支持从配置中心（如 etcd / Nacos）动态拉取，不然大促前还得发版
真正难的从来不是“怎么写限流”，而是“怎么知道它正在起作用”。
