rate.Limiter是生产级令牌桶实现，支持突发、线程安全、无锁；常见误用是混淆速率与桶容量；推荐复用而非每请求新建；漏桶适合后台任务而非HTTP接口。
用 rate.Limiter 做令牌桶，90% 场景够用了
Go 官方扩展库 golang.org/x/time/rate 提供的 rate.Limiter 就是生产级令牌桶实现，不是玩具。它支持突发、线程安全、无锁核心路径，且已通过大量高并发服务验证。
常见错误是误以为 rate.NewLimiter(rate.Every(200*time.Millisecond), 3) 表示“每秒 5 次”，其实它等价于“每 200ms 放 1 个令牌，桶最多存 3 个”——即允许瞬间连发 3 次，之后必须等 200ms 才能再发第 4 次。
- 用
limiter.Allow()非阻塞判断：适合快速拒绝，但不保证后续请求立刻能过（可能刚被抢光） - 用
limiter.Wait(ctx)阻塞等待：适合对延迟敏感的接口，比如支付回调，但需设好ctx.WithTimeout，否则可能卡死 - 别为每个请求 new 一个
Limiter：它是并发安全的，全局复用即可；按 IP 或用户 ID 区分限流时，才用sync.Map或map[string]*rate.Limiter缓存
漏桶不适合 HTTP 接口，但适合后台任务调度
漏桶强调“恒定输出速率”，天然不支持突发，HTTP 用户连点刷新、重试等行为会被硬性削峰，体验差。它真正的用武之地是内部异步任务，比如日志批量上报、消息队列消费、数据库写入批处理。
纯 Go 实现不需要 Redis 或外部依赖，核心就两行逻辑：time.Ticker 定期从 channel 取任务，select { case ch 控制入桶。桶容量 = channel 缓冲区大小，漏速 = <code>Ticker.C 的间隔。
立即学习“go语言免费学习笔记（深入）”；
- 别拿漏桶做 API 限流：用户看到的是“点了没反应”，而不是“稍等一下”，容易引发重试风暴
- 慎用
time.Sleep模拟漏出：会阻塞 goroutine，高并发下 goroutine 泄漏风险大 - 如果真要用，优先封装成函数式提交接口
Submit(func()) bool，而非暴露 channel 给业务层
滑动窗口要自己写，uber-go/ratelimit 不是你要的那个
很多人搜到 go.uber.org/ratelimit，发现它其实是“原子时钟版的令牌桶”，不是滑动窗口。它用 unsafe.Pointer + atomic 实现纳秒级精度的单次请求间隔控制，适用于低延迟微服务间调用限流，但**不统计请求数，也不支持“1 分钟内最多 100 次”这种语义**。
真正滑动窗口得自己维护时间戳队列或环形缓冲区。简单可靠的做法是用 []time.Time + sync.Mutex，每次请求时删掉过期时间戳再追加当前时间。注意：这不是 O(1)，但只要窗口粒度 ≥ 100ms、最大请求数 ≤ 1000，实际压测中 CPU 开销可忽略。
- 别用 map 按秒 key 存计数：固定窗口有临界突增问题（如 00:59.9s 和 01:00.1s 的两个请求会被算作不同窗口）
- 别在循环里调
time.Now()多次：窗口判断只调一次，所有比较基于同一个now - 若需高并发无锁，可用
ringbuffer+ CAS，但绝大多数业务没必要——先跑通带锁版本，再看 metrics 是否真成瓶颈
分布式限流绕不开 Redis + Lua，但别一上来就上
单机 rate.Limiter 在多实例部署时完全失效。此时必须引入外部协调，Redis 是最现实的选择：用 EVAL 执行 Lua 脚本保证“读+写+判断”原子性，配合 INCR + EXPIRE 模拟滑动窗口，或用 zset 存时间戳做精确滑动。
但代价明显：每次请求多一次网络 RTT，Redis 成为单点依赖，脚本写错会导致全局限流失效。所以务必遵守“先单机，再集群”的演进节奏。
- 别在 Lua 脚本里做复杂计算：只做计数和过期判断，业务逻辑留在 Go 层
- 别省略 fallback：Redis 不可用时，降级到本地
rate.Limiter，避免雪崩 - 限流 key 设计要合理：比如
rate:ip:<code>req.RemoteAddr或rate:uid:<code>userID，避免用完整 URL（易被构造恶意长 key）
限流不是越严越好，也不是算法越新越好。真正难的是定义清楚“谁该被限、为什么限、限多少”，以及把 Allow() 的返回值转化成用户能理解的响应（比如带 Retry-After header）。算法只是工具，别让它反客为主。
