正确顺序是先用SET key 0 EX 60 NX初始化再INCR，避免INCR后EXPIRE的竞态风险；固定窗口优先于滑动窗口，响应头需用Redis TTL而非本地时间计算。
Redis INCR 配合 EXPIRE 实现时间窗口计数，必须先设过期再自增
直接 INCR 后再 EXPIRE 有竞态风险：如果服务在两条命令之间崩溃或被杀，key 就会永久存在，导致后续所有限流失效。正确顺序是用 SET key 0 EX 60 NX 初始化（NX 确保只在 key 不存在时设置），再用 INCR —— 这样即使初始化失败，下一次请求仍能安全重试。
常见错误现象：INCR 出来的值越来越高，但实际请求量没那么多；或者某次部署后限流突然失灵，查 Redis 发现一堆没过期的计数 key。
- 用
SET key value EX seconds NX替代单独INCR初始化 - 后续统一用
INCR key，不要重复调用EXPIRE - 如果业务允许“窗口起始时间不严格对齐”，比如每分钟限 100 次，就用当前分钟戳做 key，如
rate:login:20240521:14:32
Go 里用 redigo 或 go-redis 调用 INCR 时，别忽略返回值类型和错误处理
INCR 返回的是整数，但 redigo 的 Int() 和 go-redis 的 Val() 可能返回 0 或 error，而 0 本身可能是合法计数值（比如第一次调用），不能靠判空或判零跳过逻辑。
使用场景：高频接口（如短信发送、登录尝试）需要立刻知道是否超限，不能等后续检查。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- redigo 中用
conn.Do("INCR", key)后，必须用redis.Int()解包，并检查 error 是否为redis.ErrNil（key 不存在）或其他网络错误 - go-redis 中
client.Incr(ctx, key).Val()返回int64，但若 key 是 string 类型非数字，会返回 0 并带redis.Nil错误 —— 此时应主动重置 key - 避免把
INCR结果直接当布尔值用，比如if incr > 0 { ... }，第一次就是 1，永远成立
窗口滑动不精确？用 Lua 脚本保证原子性比客户端逻辑更可靠
单纯靠 key 命名（如按分钟切片）只能做到“固定窗口”，无法实现“滑动窗口”（比如最近 60 秒内最多 100 次）。想精确滑动，得用 ZSET 存时间戳 + EVAL 脚本清理旧成员，但复杂度陡增。多数业务其实不需要真滑动——固定窗口 + 合理粒度（如 10 秒窗口）已足够防刷。
性能影响：Lua 脚本在 Redis 单线程中执行，长脚本会阻塞其他命令；而 INCR+EXPIRE 是两个原生命令，更快更轻量。
- 除非明确要求滑动语义（如 API 文档写死“任意 60 秒内”），否则优先用固定窗口 +
INCR - 如果真要用滑动，别在 Go 里先
ZRANGEBYSCORE再删，而是用 Lua 把查询、过滤、计数、插入打包成一个EVAL调用 - 注意 Lua 中
redis.call("ZCARD")返回的是当前集合大小，不是“是否超限”，得自己比对
限流后怎么让客户端知道被拒绝？别只 return 503
单纯 HTTP 503 不够，前端或调用方没法区分是服务宕了还是被限流了。建议在响应头里加 X-RateLimit-Remaining 和 X-RateLimit-Reset，和标准限流头对齐。
容易踩的坑：这些头的值不能靠 Go 本地时间算，得从 Redis 读取剩余时间（TTL key），否则分布式节点时间不同步会导致头信息错乱。
- 每次限流判断后，顺手调一次
TTL key，把结果转成秒填到X-RateLimit-Reset -
X-RateLimit-Remaining就是INCR返回值的反向计算（比如上限 100，当前值 98，则剩 2） - 如果
TTL返回 -2（key 不存在），说明刚初始化，剩余就是上限值
最麻烦的其实是 key 设计：用户级限流要拼用户 ID，IP 级要防代理头伪造，API 级得带路由路径。这些细节不写进 key 名，后面就只能改代码、清缓存、挨个解释为什么限流没生效。
