限流的本质是控制单位时间内的请求数量，而非简单禁止访问；Golang中常用时间窗口计数器或令牌桶/漏桶模型，后者可用time.Ticker+channel轻量实现，配合熔断器构成多层防护。
限流的本质是控制单位时间内的请求数量
限流不是简单地“禁止访问”，而是让系统在可承受范围内平稳运行。Golang 中常用两种思路：基于时间窗口的计数器（如每秒最多 100 次），或基于令牌桶/漏桶的平滑调度模型。前者实现简单但有临界突刺问题，后者更贴近真实流量分布，适合对响应稳定性要求高的场景。
用 time.Ticker + channel 实现轻量级令牌桶
不需要引入第三方库，标准库就能搭出可靠限流器。核心是用 time.Ticker 周期性向 channel 注入令牌，任务执行前从 channel 尝试取一个令牌——取到就执行，取不到就等待或拒绝。
- 初始化时设定速率，比如 rate = 10 / time.Second 表示每秒 10 个令牌
- 用 make(chan struct{}, capacity) 创建带缓冲的令牌 channel，容量即桶大小
- 启动 goroutine 调用 ticker.C 不断写入令牌，注意用 select + default 避免阻塞写入
- 业务逻辑中用 select { case 非阻塞获取，或加超时控制
用 golang.org/x/time/rate 包快速落地
官方扩展包 rate.Limiter 封装了令牌桶逻辑，支持预热、突发容量和精确等待。它内部用原子操作维护剩余令牌和上次填充时间，线程安全且性能好。
- 创建： limiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 3) 表示每 100ms 放
1 个令牌，初始桶容量为 3
- 阻塞等待： limiter.Wait(ctx) 自动计算需等待多久，支持上下文取消
- 非阻塞检查： if limiter.Allow() { ... } 立即返回 true/false，适合拒绝式限流
- 动态调整：调用 SetLimitAndBurst() 可运行时修改速率和容量，适合灰度或弹性扩缩容
并发安全与实际部署要点
单个限流器实例天然并发安全，但要注意作用域。Web 服务中常见错误是为每个请求 new 一个 Limiter，这会让限流失效；正确做法是全局复用一个实例，或按用户/租户/接口路径做 key 分片管理。
- HTTP 中间件里使用：把 limiter 存在 middleware 结构体中，避免闭包捕获导致内存泄漏
- 微服务间共用限流：可用 Redis + Lua 做分布式令牌桶，Golang 侧用 redigo 或 go-redis 调用
- 监控不可少：记录 allowed / rejected / wait_duration 指标，便于定位瓶颈和调参
- 避免过度限流：允许一定突发（burst > 1），配合熔断器（如 circuitbreaker）形成多层防护
基本上就这些。限流不复杂但容易忽略边界和可观测性，先跑通再优化。
1 个令牌，初始桶容量为 3