用 time.Ticker 直接限流易出错，因其无状态、不处理请求堆积，导致漏接 tick 而失效；正确做法是结合 channel 实现带状态的令牌桶，用 Ticker 定期补令牌、channel 控制获取与等待。
为什么用 time.Ticker 做限流容易出错
直接用 time.Ticker 配合 select 发送任务，看似能“匀速放行”，但没考虑并发请求的突发性——Ticker 只管时间，不管当前有没有待处理请求。一旦请求堆积，select 会非阻塞地丢弃未被接收的 tick，导致实际通过率远高于预期，甚至完全失效。
- 典型表现：压测时 QPS 瞬间冲高，
Ticker.C被漏接，限流形同虚设 - 根本原因：限流器必须维护“可用令牌数”状态，而
Ticker本身不带状态 - 正确思路：用
Ticker定期补充令牌，用 channel 控制获取令牌的同步与等待
用 chan struct{} 实现令牌桶核心逻辑
最轻量、无第三方依赖的实现方式是把 channel 当作“令牌池”：容量为最大并发数，每次成功从 channel 读取一个 struct{} 表示拿到一个执行许可；定时向 channel 写入（补令牌），写满则丢弃。
type RateLimiter struct {
tokens chan struct{}
ticker *time.Ticker
}
<p>func NewRateLimiter(qps int) *RateLimiter {
tokens := make(chan struct{}, qps)
// 每秒补 qps 个令牌，初始填满
for i := 0; i < qps; i++ {
tokens <- struct{}{}
}
ticker := time.NewTicker(time.Second / time.Duration(qps))
return &RateLimiter{tokens: tokens, ticker: ticker}
}</p><p>func (rl *RateLimiter) Allow() bool {
select {
case <-rl.tokens:
return true
default:
return false
}
}</p><p>// 启动补令牌 goroutine
func (rl *RateLimiter) Start() {
go func() {
for range rl.ticker.C {
select {
case rl.tokens <- struct{}{}:
default:
// 已满，不补，保持严格速率
}
}
}()
}-
Allow()是非阻塞的，适合快速失败场景；如需阻塞等待，改用 - 初始填满 + 每秒补满，等效于“每秒最多处理 qps 个请求”，但瞬时 burst 受 channel 容量限制（即最多允许 qps 个并发）
- 注意：
time.Second / time.Duration(qps)在 qps=1 时是 1s，qps=100 时是 10ms；qps 过大需检查系统 ticker 精度是否支撑
结合 context.Context 支持超时与取消
真实服务中，你不能让请求无限等待令牌。必须给 Allow() 加上上下文控制，否则一个卡住的限流器可能拖垮整个 HTTP handler。
func (rl *RateLimiter) Wait(ctx context.Context) error {
select {
case <-rl.tokens:
return nil
case <-ctx.Done():
return ctx.Err()
}
}
<p>// 使用示例：
func handler(w http.ResponseWriter, r <em>http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 100</em>time.Millisecond)
defer cancel()
if err := limiter.Wait(ctx); err != nil {
http.Error(w, "rate limited", http.StatusTooManyRequests)
return
}
// 执行业务逻辑
}- 永远避免在 HTTP handler 中调用无超时的
Allow()或裸 -
context.WithTimeout的值要明显小于业务平均响应时间，否则限流失去意义 - 不要在
Wait()后再做耗时操作——限流只保护入口，不保护后端依赖
goroutine 泄漏风险与 Stop() 的必要性
只要 *RateLimiter 实例存在且 Start() 被调用，补令牌 goroutine 就永不停止。如果 limiter 是按需创建又未显式关闭，会累积大量 goroutine，最终 OOM。
立即学习“go语言免费学习笔记（深入）”；
- 必须提供
Stop()方法：rl.ticker.Stop()+ 清空 channel（可选） - HTTP server 关闭时，应遍历所有 limiter 实例调用
Stop() - 若 limiter 生命周期与服务一致（全局单例），可在
main()退出前统一 Stop；若按租户/路径动态创建，务必绑定到对应生命周期管理器
channel + ticker 组合本身不复杂，但状态管理、上下文集成和资源回收这三点，才是线上稳定运行的关键。漏掉任意一个，都可能在流量高峰时暴露为隐性故障。
