直接用 golang.org/x/time/rate 就够了，因其 rate.Limiter 基于令牌桶、轻量无锁、高并发安全，且经生产验证；自研易踩时钟跳跃、burst失控、实例泄漏等坑；分布式场景需换 Redis 等中心化方案。
为什么直接用 golang.org/x/time/rate 就够了？
绝大多数 Golang 微服务场景下，不需要手写令牌桶——标准库的 rate.Limiter 就是基于令牌桶实现的，且经过充分压测和生产验证。它底层用 time.Now() 和原子操作控制填充逻辑，不依赖外部存储，轻量、无锁、高并发安全。
常见误区是以为“自研=可控”，但实际踩坑点远多于收益：比如未考虑时钟跳跃导致令牌误充、未对 burst 做合理约束引发突发流量穿透、或在 HTTP 中间件里忘了复用单个 rate.Limiter 实例导致内存泄漏。
-
rate.NewLimiter(10, 20)表示每秒补充 10 个令牌，初始桶容量为 20 - 调用
limiter.Allow()是非阻塞判断，返回false代表被限流 - 若需阻塞等待（如后台任务），改用
limiter.ReserveN(time.Now(), n)并检查.OK() - 注意：同一个
rate.Limiter实例必须复用，不要每次请求都new
HTTP 中间件里怎么正确挂载限流器？
限流器必须按维度隔离，不能全局共用一个实例。比如按用户 ID 限流，就得用 sync.Map 或带 TTL 的内存缓存做 key → limiter 映射；而按 API 路径限流，则可预定义 map[string]*rate.Limiter。
容易忽略的是：中间件中没做 key 规范化，比如 /user/123 和 /user/123/ 被当成两个 key；或者没限制 sync.Map 的增长，导致内存无限上涨。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 路径级限流建议用预热方式初始化：
limiters["/api/order"] = rate.NewLimiter(5, 10) - 用户级限流推荐用带过期的方案，例如
github.com/patrickmn/go-cache，key 为"user:" + userID，TTL 设为 5 分钟 - 务必在
http.HandlerFunc开头就取 limiter 实例，避免在 handler 内部多次调用Allow()导致计数错乱 - 返回状态码统一用
http.StatusTooManyRequests，并设Retry-After头（可从limiter.Reserve()的.Delay()推算）
分布式场景下 rate.Limiter 还能用吗？
不能。标准库的 rate.Limiter 是进程内状态，多实例部署时各自独立计数，等效于把 QPS 上限乘以实例数。真正需要跨节点协同限流时，必须引入中心化存储。
这时候选型不是“要不要换算法”，而是“用哪个后端”。Redis + Lua 是最常用组合，但要注意 Lua 脚本必须保证原子性，且网络延迟会直接影响限流精度。
- 避免用
INCR+EXPIRE两步操作——存在竞态，应改用单条EVAL脚本实现令牌桶逻辑 - 推荐使用
github.com/bsm/ratelimit，它封装了 Redis 令牌桶，支持滑动窗口和固定窗口两种模式 - 如果已有 etcd 集群，可用
go.etcd.io/etcd/client/v3的CompareAndSwap模拟令牌消耗，但吞吐明显低于 Redis - 别为了“一致性”强行上 ZooKeeper 或数据库——它们的 RT 波动会让限流变成不可预测的抖动源
测试限流逻辑时最容易漏掉什么？
本地单元测试常只验证“超限时返回 false”，却忽略了时间精度问题。比如用 time.Sleep(100 * time.Millisecond) 模拟间隔，但 Go 的调度和系统时钟可能导致实际休眠远长于预期，让测试通过但线上失效。
真正可靠的测试必须控制时间推进，而不是等真实时间流逝。
- 用
github.com/benbjohnson/clock替换time.Now，在 test 中手动clock.Add(1 * time.Second) - 对
rate.Limiter的测试，重点验证 burst 耗尽后是否真要等满 1s 才恢复，而不是只测第一次拒绝 - HTTP 中间件测试要覆盖边界：连续 21 次请求（burst=20）第 21 次必须被拒，第 22 次仍拒，直到 1 秒后才放行第 22 次
- 别忘了压测——用
hey -z 10s -c 100 "http://localhost:8080/api"看实际拦截率是否接近理论值
限流不是加个中间件就完事。桶大小、填充速率、维度粒度、存储选型、时钟控制——每个环节松动一点，线上就可能雪崩。最危险的，是把本地跑通当成生产可用。
