最省事的是用 github.com/go-redis/redis_rate，它基于 Lua 原子执行、适配 go-redis/v9，初始化传入 *redis.Client 和速率，调用 AllowN 时注意 key 前缀与上下文传递。
用 redis.CellRateLimiter 做令牌桶限流最省事
go 生态里直接支持 redis 分布式限流的成熟方案不多，golang.org/x/time/rate 是本地内存型，没法跨进程共享状态。真正开箱即用、带 redis 后端的，目前只有 redis.cellratelimiter（来自 github.com/bsm/redislock 的配套限流器，但更常用的是它衍生出的轻量封装，比如 github.com/go-redis/redis_rate）。后者基于 lua 脚本原子执行，单次请求完成 key 计数 + 过期设置 + 判断是否放行，没竞态风险。
实操建议：
- 用
github.com/go-redis/redis_rate，它适配go-redis/v9，不是老版本redigo或v8 - 初始化时传入
*redis.Client和每秒令牌数（rate.PerSecond(100)），别用太大的时间窗口（比如 1 小时），Redis 中 key 会堆积 - 每次限流调用
limiter.AllowN(ctx, "api:login", 1)，返回bool和剩余窗口时间（time.Duration），别只看布尔值，下游可据此做重试退避 - 注意：key 名要带业务前缀和可变参数（如
"ip:"+clientIP），否则所有请求挤同一个桶
redis.Eval 手写 Lua 实现漏桶或滑动窗口时的三个硬坑
自己写 Lua 脚本发给 Redis 看似灵活，但实际踩坑率极高。常见错误不是逻辑错，而是原子性、过期、计数精度三方面失控。
容易出问题的地方：
-
EXPIRE不能跟在INCR后面分两步走——Lua 脚本内必须用PEXPIREAT配合redis.call("TIME")算毫秒级过期时间，否则并发时可能设了过期但 key 已被删，或多个 INCR 后只设一次过期 - 滑动窗口若用 zset 实现，
ZREMRANGEBYSCORE必须在ZADD前执行，且用redis.call("ZCARD")检查长度，不能靠客户端判断后决定是否清理——网络延迟会导致窗口数据漂移 - 漏桶若用
GET+SET模拟“上次滴落时间”，必须用redis.call("GETSET")，否则GET和SET之间有间隙，高并发下桶水位计算错误
为什么不用 SETNX + EXPIRE 组合做简单计数限流
有人想用 SETNX key 1 EX 60 初始化 + INCR 计数，看似简洁，但这个组合在 Redis 2.6.12 之后才支持原子性，而很多生产环境还在用 2.4 或 2.6 早期版；更重要的是，SETNX 成功不代表 key 一定没过期，它不检查 TTL，导致旧 key 复活、计数错乱。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
更现实的问题是：
- 如果服务重启或 Redis 故障，
SETNX失败后没有 fallback 逻辑，整个限流就失效了（变成无限制） -
INCR没有内置速率判断，你得额外GET再比对，两次 RTT + 条件竞争，不如一个 Lua 脚本搞定 - 当限流阈值是“每分钟最多 100 次”，用
SETNX+EXPIRE只能实现“固定窗口”，会出现窗口切换时的脉冲流量（比如第 59 秒打 100 次，第 60 秒又打 100 次）
在 Gin 中集成限流中间件要注意的上下文生命周期
把限流逻辑塞进 Gin 的 func(c *gin.Context) 里很简单，但关键在 ctx 传递和错误处理。很多人直接用 context.Background() 调 Redis，一旦 Redis 延迟升高，整个 HTTP 请求会被拖死，且无法感知超时。
正确做法：
- 用
c.Request.Context()传给limiter.AllowN()，这样 HTTP 超时、客户端断连都能中断 Redis 请求 - 限流失败不要直接
c.AbortWithStatusJSON(429, ...)，先检查错误类型：redis.Nil是 key 不存在（正常），context.DeadlineExceeded是 Redis 超时（应降级为允许或返回 503），redis.Timeout同理 - 别在中间件里硬编码限流 key，抽成函数，比如
genRateKey(c) string，方便按 path、header、query 组合策略（如/pay接口按 user_id 限，/status按 IP 限）
Redis 分布式限流真正的复杂点不在脚本或库，而在“什么时候该拒绝”“拒绝后怎么反馈”“失败了要不要兜底”。限流器返回 false 只是信号，后续的降级、日志标记、指标上报，才是线上系统稳不稳的关键。别让一个 AllowN 调用成了整个请求链路的单点故障源。
