滑动窗口限流必须用原子操作+预分配slice或Redis ZSET实现，禁用time.Now()+map；单机用[]int64+atomic，分布式用ZSET+Lua，时间必须统一为服务端TIME。
滑动窗口限流在 Go 中不能靠 time.Now() + map 简单拼凑，否则不是真滑动，而是固定窗口；并发写 map 会 panic，全局锁又拖垮性能——得用原子操作+预分配 slice 或 Redis ZSET 才靠谱。
用 []int64 + atomic 实现轻量单机滑动窗口
适合 QPS 中等、不跨进程的场景（如网关单实例、内部服务）。核心是避免锁和 GC，靠预分配数组 + 原子计数。
- 窗口总长
windowSec（秒），分片数shards，每片时长 =windowSec * 1e9 / shards（纳秒） - 当前片索引 =
(now.UnixNano() / shardDuration) % int64(shards)，注意先转int64防溢出 - 过期判断必须用绝对时间：
slice[i]对应的时间戳是i * shardDuration，和now.UnixNano() - windowSec*1e9比较，不能只看索引差 - 每次请求进来时「懒清理」：遍历所有片，把时间戳早于窗口起点的对应位置清零（或跳过累加）
- 更新必须用
atomic.AddInt64(&slice[i], 1)，不能直接slice[i]++
用 Redis ZSET + Lua 实现分布式滑动窗口
多实例部署时，单机方案完全失效；INCR+EXPIRE 是固定窗口，且 EXPIRE 不准时——必须用 ZSET 存时间戳，靠 Lua 原子执行统计+清理。
-
ZADD rate:uid <timestamp> <req_id>：score 用毫秒/秒级时间戳（统一精度），member 可用随机值或 clientID - Lua 脚本内必须用
redis.call("TIME")获取 Redis 服务端时间，避免各机器 NTP 不同步导致窗口错位（误差超窗口粒度就失效） - 三步不可拆：
ZCOUNT统计窗口内请求数 → 判断是否超限 →ZADD新请求 →ZREMRANGEBYSCORE清理过期项 - 别用 pipeline 模拟原子性：网络延迟和重试会让结果不可靠；
redis.Client.Eval是唯一安全方式 - 返回值是
int64，不是 bool，Go 里要显式转成int64(result)再判断
为什么别用 map[int64]int 或 sync.Map 直接存时间片
看似直观，但实际踩坑密集：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 多个 goroutine 并发读写同一
map会触发panic: concurrent map read and map write - 用
sync.RWMutex锁整个 map，高并发下争用严重，QPS 断崖下跌 -
sync.Map虽线程安全，但它是为读多写少设计的；滑动窗口频繁更新+遍历，反而比原生 map + 分片锁更慢 - 时间片粒度设太细（比如 100ms 窗口分 600 片），内存占用陡增，且过期检查成本变高
- 用
time.Timer或time.Ticker定时清理过期桶——触发不准，还可能堆积 goroutine
常见误配和线上事故点
这些细节不处理，压测时可能一切正常，上线后突发超限或大面积拒绝：
- Gin 中取 IP 用
r.RemoteAddr而不是r.Header.Get("X-Real-IP")，没配TrustedProxies就拿到 Nginx 内网地址，限流 key 失效 - Redis Lua 脚本里用
ARGV[3]当前时间，却传了time.Now().Unix()，而非服务端TIME返回值，NTP 偏差 >1s 就漏放行 - 滑动窗口参数写死在代码里，没暴露为配置项，扩容时窗口大小无法动态调优
- 没对 ZSET 做定期
ZCARD监控，zset 膨胀到几万成员后，ZCOUNT和ZREMRANGEBYSCORE延迟飙升 - 健康检查接口（如
/health）被限流器拦截，K8s liveness probe 失败，触发滚动重启
滑动窗口真正的难点不在算法本身，而在于时间语义的一致性——本地时间、Redis 时间、客户端时间，只要有一处没对齐，窗口就“滑歪”了。生产环境必须强制 NTP 同步，并用服务端时间戳作为唯一权威源。
