最简限流装饰器需用闭包捕获 rate.Limiter 实例，避免每次调用新建或全局共用；推荐 rate.Every 而非手动计算速率；Wait 必须传入 context 且需处理 error。
用 golang.org/x/time/rate 实现最简限流装饰器
Go 没有原生装饰器语法，但靠闭包 + rate.Limiter 能写出语义清晰、零依赖的限流包装器。核心不是“模拟 Python 的 @decorator”，而是把限流逻辑和业务函数解耦。
常见错误是直接在函数里 new 一个 rate.Limiter，导致每次调用都新建限流器，完全失效；或者把限流器设成全局单例，多个函数共用一个桶，互相干扰。
- 限流器必须按需实例化，通常作为包装器的参数或闭包捕获变量
- 推荐用
rate.Every(100 * time.Millisecond)而非手动算rate.Limit，更直观 - 注意
limiter.Wait(ctx)可能返回context.DeadlineExceeded，别漏掉 error 处理
func WithRateLimit(limiter *rate.Limiter, fn func()) func() {
return func() {
if err := limiter.Wait(context.Background()); err != nil {
log.Printf("rate limit exceeded: %v", err)
return
}
fn()
}
}
<p>limiter := rate.NewLimiter(rate.Every(200*time.Millisecond), 1)
wrapped := WithRateLimit(limiter, func() { fmt.Println("hello") })
带 context 和 error 透传的生产级封装
真实场景里，函数往往要接收 context.Context、返回 error，且调用方需要感知限流失败还是业务失败。这时候不能简单包装无参无返回值函数。
容易踩的坑：把 ctx 硬编码进包装器内部，导致上游 timeout 或 cancel 无法传递；或者把限流错误和业务错误混在一起返回，下游无法区分重试策略。
立即学习“go语言免费学习笔记（深入）”；
- 限流等待必须用传入的
ctx，不能用context.Background() - 限流失败（如
rate.ErrLimited）应单独判断并返回，不要吞掉 - 如果业务函数本身可能 panic，建议在包装器里 recover，否则限流器状态可能异常
func WithRateLimitCtx[T any](limiter *rate.Limiter, fn func(context.Context) (T, error)) func(context.Context) (T, error) {
return func(ctx context.Context) (T, error) {
if err := limiter.Wait(ctx); err != nil {
return *new(T), fmt.Errorf("rate limited: %w", err)
}
return fn(ctx)
}
}
多个函数共享限流器时的资源隔离问题
一个 rate.Limiter 实例可以被多个函数共用，但要注意：它只控制“总速率”，不区分调用来源。如果你有 sendEmail 和 sendSMS 两个函数，共用同一个 limiter，那发短信发多了，发邮件就会被卡住。
这不是 bug，是设计使然。但很多同学误以为“加了限流就安全了”，结果线上发现某类请求突然全挂，查半天才发现是被另一条路径吃掉了配额。
- 按功能维度拆 limiter：比如每种 API 路径、每种消息类型、每个租户 ID 单独配一个
- 高频小函数（如日志打点）建议用
AllowN非阻塞判断，避免 Wait 卡住关键路径 - 注意
rate.Limiter不是线程安全的？错——它是并发安全的，但别把它当锁用
测试限流包装器时最容易漏掉的 case
写单元测试时，光测“能跑通”没用。限流逻辑的边界行为才是重点，而这些恰恰最难 mock。
典型遗漏：没测连续超速触发限流、没测 context cancel 后 Wait 是否立即返回、没验证 burst 值是否真正生效（比如设了 burst=5，但第 6 次调用没被拦住）。
- 用
rate.NewLimiter(rate.Limit(1), 1)+time.Sleep组合，比 mock 时间更可靠 - 测试 burst 行为时，用
AllowN(time.Now(), n)手动检查，比等 Wait 更快更确定 - 别忘了并发测试：起 10 个 goroutine 同时调用，看是否真能压住速率
限流不是加个中间件就完事，关键在“谁在限、按什么粒度限、失败后怎么反馈”。这些细节不抠清楚，上线后要么形同虚设，要么误伤正常流量。
