Go 令牌桶限流器怎么写才不被并发打穿
直接说结论：用 sync.Mutex 或 atomic 手动实现令牌桶，在高并发下大概率成为性能瓶颈；真正扛得住压测的是基于 time.Ticker + atomic 的“预分配”模式，或直接用 golang.org/x/time/rate.Limiter ——但它默认不是线程安全的“每请求扣一次”，得配合 AllowN 和时间窗口校验。
常见错误现象：rate.Limiter.Allow() 在 goroutine 密集调用时出现误放行，比如设定 100 QPS，实测跑到 300+；根本原因是没考虑 Allow 只检查“此刻有没有令牌”，而没对“这一秒内已放过多少次”做原子计数。
- 必须用
AllowN(time.Now(), n)替代Allow()，显式传入当前时间，避免因调度延迟导致令牌计算偏移 - 如果要做“严格每秒 N 次”，别依赖
Limiter单实例，加一层sync.Map按 key（如用户 ID）分桶，否则全局桶会把不同用户的请求互相挤占 -
rate.NewLimiter(100, 100)中第二个参数是初始令牌数，不是并发上限——设太小（如 1）会导致首请求就拒绝，设太大（如 1000）会让突发流量瞬间穿透
漏桶限流在 Go 里为什么很少人用
因为漏桶本质需要维护一个队列 + 定时匀速出队，在 Go 里意味着要么用 time.Ticker 驱动后台 goroutine 消费，要么用带缓冲 channel 做“水槽”，但两者都有硬伤：前者增加调度开销和 GC 压力，后者缓冲区大小难预估，溢出就丢请求。
实际场景中，漏桶只在极少数需求里必要——比如下游 API 明确要求“请求间隔不能小于 100ms”，此时令牌桶无法保证最小间隔，必须用漏桶语义。但实现上，别自己手撸带锁队列，推荐用 github.com/uber-go/ratelimit 的 newAtomicRateLimiter，它用 atomic 模拟漏桶的“固定速率滴落”，无 goroutine、无锁、延迟可控。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 自己实现漏桶时，若用
time.AfterFunc延迟投放令牌，会随请求数增长创建大量 timer，触发runtime.timer性能告警 - 用 channel 实现漏桶时，
select { case 在 channel 满时直接阻塞 goroutine，QPS 上不去还容易堆积 goroutine -
uber-go/ratelimit的Take()返回的是“该等多久”，不是布尔值——你要自己time.Sleep或丢弃请求，这点容易忽略导致限流失效
如何让限流器支持动态 QPS 调整而不重启
关键不是换算法，而是替换底层速率对象。原生 rate.Limiter 的 limit 字段是 unexported 的，没法运行时改；正确做法是封装一层，用 atomic.Value 存当前 *rate.Limiter，每次调整时新建一个并原子替换。
使用场景：灰度发布时按服务名动态降级 QPS，或根据 CPU 使用率自动缩容限流阈值。
- 替换时不要直接
atomic.StorePointer，用atomic.Value.Store存接口，类型安全且避免 unsafe 操作 - 新
Limiter初始化要用rate.Every(time.Second / newQPS)，别用float64除法再转time.Duration，整数除法更稳（比如100QPS →time.Second / 100） - 旧 Limiter 不会立即失效，但后续请求都走新实例，无需担心中间状态不一致
为什么本地测试通过的限流器一上生产就失效
核心问题：本地用 time.Now() 没问题，生产环境容器里可能有多个副本共享同一套限流逻辑，但没做分布式协调；或者用了本地内存缓存（如 sync.Map），结果负载均衡把同一用户打到不同实例，限流完全失准。
这不是算法问题，是架构误用。高频服务必须区分“单机限流”和“集群限流”——前者用 rate.Limiter 没毛病，后者必须引入 Redis 或 etcd。
- Redis 实现用
INCR + EXPIRE组合，但注意EXPIRE不是原子的，得用 Lua 脚本包住，否则可能 key 存在但没过期时间 - 用
github.com/go-redis/redis_rate时，它的AllowN默认用server time，如果 Redis 服务器时间与应用服务器偏差 >1s，就会误判超限 - etcd 的 lease + key TTL 方案看似优雅，但 watch 事件有延迟，不适合毫秒级精度限流，更适合分钟级配额控制
最常被忽略的一点：无论用哪种方案，都得在 HTTP middleware 里统一拦截，而不是在每个 handler 里零散调用——漏掉一个 handler，整个限流策略就塌一角。
