该用 time.Ticker 而非 time.AfterFunc 实现周期性限流调度，因其准时且可复用；需全局复用并手动 Stop() 防泄漏；令牌桶优于漏桶，推荐 atomic.Int64 无锁实现；限流判断须毫秒级完成，拒绝即返，不阻塞；context.WithTimeout 在限流中间件中无意义。
限流中间件该用 time.Ticker 还是 time.AfterFunc？
别用 time.afterfunc 做周期性限流调度——它不保证准时，也不复用，高并发下会堆积大量 goroutine。真正可控的节奏靠 time.ticker，但要注意：必须手动 stop()，否则 ticker 会泄漏并持续触发。实际部署中，常见错误是把 ticker 声明在 handler 内部，导致每次请求都新建一个，几秒后就卡死。
正确做法是全局复用一个 *time.Ticker，配合原子计数器（sync/atomic）或带 CAS 的 ring buffer。例如每秒重置一次计数器，比每次请求都检查时间戳快一个数量级。
令牌桶 vs 漏桶：Go 中该选哪个实现？
漏桶天然串行，不适合高并发场景；令牌桶能预分配、支持并发 CAS 更新，更适合 Go 的无锁优化。但直接手写带锁的 sync.Mutex 令牌桶，在 QPS > 5k 时锁争用明显。推荐用 atomic.Int64 模拟令牌池：
- 用
atomic.LoadInt64读当前令牌数 - 用
atomic.CompareAndSwapInt64尝试扣减，失败则拒绝 - 后台 goroutine 每 100ms 补发
rate / 10个令牌（避免浮点运算）
注意补令牌不能无节制——要加 atomic.MaxInt64 截断，否则突发空闲后令牌溢出，瞬间击穿限流。
如何让中间件不拖慢正常请求路径？
限流判断必须在毫秒级完成，任何阻塞操作（如日志写磁盘、HTTP 调用、mutex 重入）都会放大延迟。关键原则：只做内存计算，拒绝即返，不记录详情日志。
- 用
http.HandlerFunc包裹，不要用net/http.Handler接口实现体（额外接口调用开销） - 拒绝响应统一用
http.StatusTooManyRequests+ 空 body，避免 JSON 序列化 - 统计指标（如当前请求数）用
atomic.AddInt64，别用 map + mutex - 配置参数（如
limit、burst）初始化后只读，避免 runtime 解析
为什么 context.WithTimeout 在限流中间件里基本没用？
限流本身是准入控制，不是下游调用——它发生在 handler 执行前，此时 request context 还没传给业务逻辑，加 timeout 只会让中间件自己超时返回，对限流逻辑无意义。真正需要超时的是后端服务调用，那属于业务层职责，不该混进限流中间件。
更隐蔽的问题是：有人用 context.WithTimeout 包裹整个 handler 链，结果限流拒绝后 context 仍被 cancel，导致后续中间件（如 trace 注入）误判为超时。限流中间件应完全无视 context 生命周期，只看当前请求是否符合速率规则。
复杂点在于 burst 容量和恢复节奏的平衡——设得太松扛不住脉冲，太紧又伤体验；而这个阈值没法靠代码自动调优，得靠线上 rate 和 burst 的监控曲线反复验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
