生产环境限流应直接使用 golang.org/x/time/rate，它由 Go 官方维护、经高并发验证，基于原子操作和时间轮实现；错误用法包括 Limit 单位混淆、误用 Allow()、固定窗口临界问题及漏桶适用场景错配。
Go里用 golang.org/x/time/rate 做限流最省事
生产环境别手写令牌桶，直接用标准扩展库 rate —— 它是 Go 官方维护、经过百万级 QPS 验证的实现，底层用原子操作+时间轮优化，比手写锁版快且线程安全。
常见错误是把 rate.Limit 当成每秒请求数传错：比如想限 100 QPS，却写成 rate.Limit(100)，这没问题；但若想限“每 100ms 最多 10 次”，就得换算成每秒 100 次（rate.Limit(100)），再配桶容量 10，否则突发流量会直接打穿。
-
rate.NewLimiter(rate.Limit(100), 10)：每秒生成 100 个令牌，桶最多存 10 个 → 允许瞬间 10 请求，之后匀速放行 - 不要用
Allow()判断后才处理逻辑，它不阻塞；高并发下建议用Wait(ctx)，配合超时控制，避免 goroutine 积压 - 注意
rate包默认以“秒”为单位，改用毫秒需手动换算：限 50 次/200ms →rate.Limit(250)（50 ÷ 0.2），桶容量设 50
固定窗口限流在教学场景里最容易踩坑
新手常照抄教程写 FixedWindowLimiter，但忽略临界问题：比如限 100 次/秒，恰好在 0.99s 和 1.01s 各来 100 请求，实际 0.02s 内就进了 200 次 —— 这不是代码 bug，是算法固有缺陷。
它只适合学习理解“计数+重置”逻辑，或低频后台任务（如每小时发一次邮件）。真要用，必须加随机抖动或降级为滑动窗口（用 Redis Sorted Set 或环形数组模拟），否则线上等于没限。
立即学习“go语言免费学习笔记（深入）”；
- 时间判断别用
time.Now().Second()取整，误差大；应记录lastReset时间点，每次用now.Sub(l.lastReset) > l.window判断是否过期 - 并发下不加
sync.Mutex或atomic，计数器必然错乱 —— 即使看起来“偶尔准”，也是竞态未暴露 - 桶容量和窗口大小别设太小：比如限 1 次/秒，窗口 1s，实际可能因调度延迟导致连续拒绝，体验极差
漏桶算法在 Go 里更适合保护下游而非防刷
漏桶本质是“拉模式”：你得主动从 channel 或队列里取任务执行，而不是让请求等令牌。所以它天然适合控制对数据库、第三方 API 的调用节奏，不适合 HTTP 接口直连限流 —— 因为每个请求要排队，延迟不可控。
用 buffered channel 实现漏桶看似简单，但容易卡死：worker 数量不够、channel 满了又没人消费，新请求直接被 select{case bucket 拒绝，此时你得自己处理降级逻辑，不是单纯返回 429。
- 桶大小（channel 容量）设太大，内存占用高；太小，拒绝率飙升 —— 建议按下游服务 P99 响应时间 × 目标并发数预估
- worker 数量别硬编码，应随 CPU 核心数或下游连接池大小动态调整，否则单核跑 10 个 worker 反而拖慢
- 漏桶不解决“突发”，只解决“输出恒定”；想防爬虫刷接口，它不如令牌桶直接；想保 DB 不被打爆，它比令牌桶更稳
分布式限流绕不开 Redis + Lua 原子操作
单机限流器在 K8s 多副本或网关集群下完全失效。这时必须用外部存储，而 Redis 是事实标准 —— 但直接用 INCR + 过期时间有竞态：两个请求同时读到 0，都写 1，计数就少 1。
正确做法是用 Lua 脚本保证“读-算-写”原子性，例如用 eval 执行一段脚本判断当前窗口内请求数是否超限。Go 里用 redis.Conn.Do("EVAL", script, keys, args...) 调用，别拆成多条命令。
- 脚本里别用
redis.call("TIME")，精度只有秒级；应传入客户端时间戳，服务端校验偏差（防篡改） - key 设计要带业务维度：比如
rate:api:/user/profile:ip:192.168.1.1，避免全局限流误伤正常用户 - Redis 故障时必须有降级策略：比如 fallback 到本地令牌桶，或直接放行（按业务容忍度选），不能卡住整个链路
真正难的不是写限流代码，而是确定“限多少”和“怎么降级”。QPS 阈值得靠压测找拐点，不是拍脑袋；熔断、排队、降级响应格式，这些决策比算法本身影响更大。写完 Allow() 得立刻想：超限时日志记什么？告警怎么触发？前端要不要友好提示？
