滑动窗口限流不能仅用时间戳差判断，因会漏掉跨窗口请求聚合；需用环形缓冲区+原子操作分片计数，配合定时 ticker 清理过期桶，并确保桶数量与粒度匹配窗口时长。
滑动窗口限流为什么不能只用 time.Now().Unix() 算时间戳差
直接用当前时间戳减去请求时间戳判断是否超窗，会漏掉跨窗口的请求聚合。比如窗口 1s、每秒最多 100 次，但实际在 0.9s–1.8s 这 0.9s 内来了 150 次——它没超任一整秒窗口（0–1s 或 1–2s），却明显超出速率。滑动窗口必须支持「任意起始点向前回溯固定时间长度」的计数，本质是维护一个带时间戳的队列或分片桶。
sync.Map 不适合做滑动窗口的底层存储
虽然 sync.Map 支持并发读写，但它不提供原子性的范围遍历 + 条件删除。滑动窗口需要定时清理过期条目（或按需清理），同时累加最近 N 毫秒内的请求数。用 sync.Map 存每个请求时间戳，清理时只能全量遍历——O(n) 开销且无法保证清理过程与计数原子性。更稳的做法是用分片数组 + 原子计数器，或环形缓冲区。
- 推荐用固定大小的环形切片（如 100 个 slot），每个 slot 存该毫秒/10ms 区间内的请求数，配合
atomic更新 - 若精度要求高（如 1ms 窗口），用
[]int64+atomic.AddInt64，索引通过(now.UnixMilli() % windowSizeMs)计算 - 注意：
UnixMilli()在 Go 1.17+ 才有，旧版本需用now.UnixNano() / 1e6
如何用 time.Ticker 安全重置计数器
别在每次请求里检查时间并手动清空旧桶——高并发下可能多个 goroutine 同时触发重置，导致计数归零或重复清零。正确做法是用独立 goroutine 驱动定时器，只负责把过期 slot 归零，其他 goroutine 只读写当前活跃 slot。
- 启动时开一个
go func()，用time.NewTicker(10 * time.Millisecond)（对应你桶的时间粒度） - 每次 tick 触发时，计算要清零的 slot 下标，用
atomic.StoreInt64(&buckets[idx], 0) - 主逻辑里只做两件事：1）获取当前 slot 下标；2）
atomic.AddInt64(&buckets[idx], 1)；3）遍历最近 N 个 slot 求和 - 求和时注意边界：从当前下标往前数
windowSizeMs / slotMs个位置，用模运算绕回
实际限流判断里最容易错的边界是「窗口长度 vs 桶数量」
假设你要实现「1 秒内最多 100 次」，但用了 100 个 slot、每个代表 10ms——那窗口实际是 100 × 10ms = 1s，没问题；但如果误设成 50 个 slot，就只覆盖了 500ms，结果会严格到近乎拒绝所有流量。反过来，如果桶太多（比如 1000 个 slot 表示 1s），单个 slot 粒度太细，小流量可能打散在多个 slot，导致统计值偏低、限流变松。
- 桶数量 =
windowDuration / slotDuration，必须整除，否则窗口长度不准 - slotDuration 通常取 10ms 或 100ms：太小（1ms）导致 ticker 频率过高；太大（1s）退化成固定窗口
- 检查方式：打印
len(buckets)和slotDuration * len(buckets)，确认等于目标窗口时长
滑动窗口真正的复杂点不在代码行数，而在时间对齐——系统时钟跳变、goroutine 调度延迟、ticker 实际间隔抖动，都会让 slot 边界漂移。生产环境建议加一层时间校准（比如每 10 秒用 time.Now() 重新计算起始偏移），或者直接用成熟库如 golang.org/x/time/rate 的 Limiter（虽是令牌桶，但效果接近且更稳）。
