滑动窗口计数器不能用无锁map+time.Now()，因并发读写panic、遍历删key性能差且时间戳取整导致统计偏差；应使用预分配原子数组分片；漏桶禁用time.Ticker，需按需补token并防时钟回拨；rate.Limiter是令牌桶非漏桶；分布式必须用Redis ZSET+Lua+服务端时间。
滑动窗口计数器为什么不能用 map + time.Now() 判断过期
直接用 map[int64]int 存每个时间戳的请求数，再每次请求时遍历删掉 time.now().unix() - 60 之前的 key，这不是滑动窗口，是固定窗口，且高并发下必 panic。现象是程序运行几秒后突然崩溃，报 concurrent map read and map write ——因为没加锁，而多个 goroutine 同时读写 map 是 go 运行时明确禁止的。
就算加了 sync.RWMutex，性能也极差：每秒上千请求时，遍历 map 删除旧 key 的成本线性增长，CPU 毛刺明显。更关键的是逻辑错误：它只保留“整秒对齐”的时间戳，比如窗口是 60 秒，但请求发生在 1715532841.321 和 1715532841.999，这两个时间戳取整后都是 1715532841，会被塞进同一个 key；而 1715532840.999 却被算作上一秒，提前清掉——导致统计漏掉近 1 秒的流量。
真正滑动窗口必须支持任意时刻往前推 N 秒的累计值，所以得保留带精度的时间分片或原始时间戳。推荐做法：
- 单机场景：预分配
[]int64，长度 = 窗口秒数 / 分片毫秒数（如 60 秒窗口、100ms 分片 → 长度 600），用atomic.AddInt64更新对应 slot - 索引计算必须用
(now.UnixNano() / shardDuration) % int64(shards)，且shardDuration要能整除窗口总长，否则边界错位 - 过期判断不能只比索引差，得用绝对时间：某 slot 对应起始纳秒 =
slotIndex * shardDuration，和now.UnixNano() - windowSec*1e9比较
漏桶算法为什么不能用 time.Ticker 定期补 token
用 time.Ticker 每 100ms 往 channel 塞一个 token，再从 channel 取 token 放行请求，这看着像漏桶，实则是硬编码节奏的“假漏桶”。问题在于它完全不响应请求到达节奏：如果连续 5 个请求在 2ms 内抵达，Ticker 才 tick 了一次，channel 里只有 1 个 token，其余 4 个全拒——但这不是限流，是丢包；而真正的漏桶应允许“匀速漏出”，即只要桶里有 token 就放行，没 token 才等。
更严重的是时钟回拨风险：time.Now() 可能因 NTP 校正倒退，导致补 token 时算出负增量，token 数暴增，限流形同虚设。生产环境必须用单调时钟。
立即学习“go语言免费学习笔记（深入）”；
正确做法是按需补桶：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 记录上次更新时间
lastTime和当前 token 数tokens，都用atomic.Value或sync.Mutex保护 - 每次请求来时，用
runtime.nanotime()算真实流逝纳秒，按速率折算应增加的 token 数：delta := (now - lastTime) * rate / 1e9 -
tokens = min(capacity, tokens + delta)，再判断是否 ≥ 1 并扣减 - 别用
float64做中间计算，统一用int64纳秒+整数速率，避免浮点误差累积
rate.Limiter 是令牌桶，不是漏桶，别混淆语义
golang.org/x/time/rate.Limiter 底层是平滑令牌桶（smooth token bucket），不是严格意义的漏桶。它的 Allow() 或 Wait() 行为本质是：“检查从现在往前推 burst 容量所需时间是否已过”，而非维护一个持续流动的水桶。这意味着它天然支持突发（burst），而漏桶强调恒定输出速率。
常见误用：
- 以为
rate.NewLimiter(rate.Every(200*time.Millisecond), 3)表示“每秒 5 次”，其实它允许瞬间连发 3 次，之后必须等 200ms 才能发第 4 次 - 传给
AllowN()的时间戳截断到秒级（如time.Now().Unix()），导致窗口错位，同一秒内多次调用全被当作同一时刻，放行过多 - 为每个 HTTP 请求 new 一个
Limiter，既浪费内存又失去复用意义；应按用户 ID 或 IP 做 key 缓存，用sync.Map或分片 map
如果你真需要漏桶行为（比如日志批量上报要严格匀速），优先用 rate.Limiter.ReserveN() 查剩余等待时间，它已接近漏桶语义；自己实现时，务必处理时钟回拨和原子状态更新。
分布式场景下，Redis ZSET + Lua 是唯一靠谱方案
单机滑动窗口在多实例部署时直接失效：各机器本地时间不同步，哪怕误差仅 200ms，60 秒窗口就可能错开 1/3。用 INCR + EXPIRE 更糟——两个命令非原子，断连时 key 永久存在（漏限）或永久丢失（误限），且根本无法统计“过去 N 秒”这个动态范围。
必须用 Redis ZSET：
-
ZADD rate:uid <timestamp_ms><req_id></req_id></timestamp_ms>，score 用毫秒级时间戳，member 用唯一标识（如 traceID） - Lua 脚本内必须调
redis.call("TIME")获取服务端时间，拼成毫秒级时间戳：seconds * 1000 + microseconds / 1000 - 三步原子执行：先
ZCOUNT key (now_ms - window_ms) +inf统计，再判断是否 ≤ max，最后ZADD新请求 +ZREMRANGEBYSCORE清理过期项 - Go 层别传时间戳进去，Lua 里算；也别用 pipeline 模拟原子性，网络抖动会让结果不可靠
最容易被忽略的点：Redis 服务端必须开启 NTP（推荐 chrony），且时钟误差压到 100ms 内；否则哪怕脚本写得再完美，时间基准一歪，整个窗口就垮了。
