滑动窗口限流不能用 time.Now() + map 实现，否则是固定窗口且并发写 map 必 panic；单机应预分配 []int64 + atomic，分布式必须用 Redis ZSET + Lua 精确实现。
滑动窗口限流在 Go 中不能靠 time.Now() + map 拼凑出来，否则就是固定窗口，不是真滑动；并发写 map 会直接 panic，加锁又拖垮性能——得用预分配 []int64 + atomic 或 Redis ZSET + Lua 才能落地。
为什么 map[int64]int 直接存时间片会 panic
看似直观：用时间戳做 key，计数做 value。但实际运行时，多个 goroutine 并发读写同一个 map，Go 运行时会立刻触发 panic: concurrent map read and map write。这不是偶发，是必然。
-
sync.Map不适合：它是为「读多写少」设计的，而滑动窗口每请求都要更新+遍历，性能反而比原生map+ 分片锁更差 -
sync.RWMutex锁整个map：高并发下争用严重，QPS 断崖下跌，实测 5k QPS 场景下吞吐掉到 800 - 用
time.Timer定时清理过期桶：触发不准，还可能堆积 goroutine，线上已有多起因 timer 延迟导致内存持续上涨的事故
单机用 []int64 + atomic 怎么写才不翻车
核心是预分配数组 + 原子操作 + 绝对时间判断。适用于网关单实例、内部服务等 QPS 中等（≤2k）、不跨进程的场景。
- 窗口总长
windowSec（秒），分片数shards，每片时长 =windowSec * 1e9 / shards（纳秒） - 当前片索引必须写成
(now.UnixNano() / shardDuration) % int64(shards)，且%前一定要转int64，否则溢出后索引错乱 - 过期判断不能只看索引差，得用绝对时间：
if now.UnixNano()-bucketTimestamp > windowSec*1e9，其中bucketTimestamp = index * shardDuration - 每次请求进来先「懒清理」：遍历所有片，把时间戳早于窗口起点的对应位置清零（或跳过累加）
- 更新必须用
atomic.AddInt64(&slice[i], 1)，绝不能写slice[i]++
分布式必须用 ZSET + Lua，INCR+EXPIRE 是伪滑动
INCR key 配 EXPIRE key 看似简单，实则是固定窗口：第 59 秒进 100 请求，第 0 秒又进 100，系统认为两个窗口互不干扰，实际 2 秒内 200 次——这就是临界流量翻倍。
立即学习“go语言免费学习笔记（深入）”；
- Lua 脚本里必须调
redis.call("TIME")获取 Redis 服务端时间，拼成毫秒级整数：seconds * 1000 + math.floor(microseconds / 1000)，不能传time.Now().UnixMilli() -
ZREMRANGEBYSCORE必须放在ZADD前，否则刚插入的请求可能被下一波清理误删 - member 必须唯一，建议用
"req:" + uuid.NewString()[:8]，避免同一毫秒内多次请求被覆盖 - Go 调用
client.Eval时，KEYS 列表只传业务标识（如"rate:ip:192.168.1.100"），ARGV 按顺序传窗口左边界、当前时间戳、最大请求数、member 值 - 返回值是
int64，不是 bool，Go 侧要显式转：result.([]interface{})[0].(int64) == 1
容易被忽略的三个硬伤
一是时间片粒度设太细（比如 100ms 窗口分 600 片），内存占用陡增，过期检查成本也变高；二是 ZSET 不主动清理，QPS 1k 的服务一天就是 8600 万条，Redis 内存撑爆；三是没开 NTP 同步（推荐 chrony），服务端时间误差超 100ms，滑动窗口就失效。
