滑动窗口算法的核心逻辑是维护每个请求的时间戳并动态剔除过期项，确保仅统计当前时间点向前 windowSize 时间内的有效请求；关键在于保留时间信息、避免内存泄漏，而非简单分桶计数。
滑动窗口算法的核心逻辑是什么
滑动窗口不是简单地把时间切分成固定段再计数，而是让每个请求“自带有效期”，只统计当前时间点往前 windowSize 时间内所有未过期的请求。关键在于：不能只靠一个全局计数器，必须保留请求的时间戳信息，否则无法剔除过期请求。
常见错误是用 map[time.Time]int 存所有历史请求——内存无限增长；或者用固定数组模拟窗口但忽略时间漂移（比如窗口从 00:00 开始，实际请求可能跨多秒到达）。正确做法是用有序结构或滚动桶 + 时间对齐。
用 sync.Map + 时间桶实现轻量级滑动窗口
适用于 QPS 不高（windowSize / bucketSize 个桶的数据。
-
windowSize = 1 * time.Second，bucketSize = 100 * time.Millisecond→ 总共维护 10 个桶 - 每次请求到来时，计算所属桶索引：
bucketIndex := int(time.Now().UnixMilli() / bucketSize.Milliseconds()) % totalBuckets - 写入前先清空已过期桶（即索引不匹配当前时间范围的桶），再累加当前桶计数
- 判断是否超限：遍历所有有效桶求和，若 ≥
maxRequests则拒绝
注意：sync.Map 虽线程安全，但遍历非原子操作，需配合 sync.RWMutex 或改用 []int64 + atomic 操作更高效。
立即学习“go语言免费学习笔记（深入）”；
使用 go-cache 实现带 TTL 的滑动窗口
当需要精确到毫秒级、且请求分布稀疏（比如 API 调用间隔长），用带自动过期的缓存更稳妥。go-cache 本身不支持范围查询，但可配合时间戳 key 设计：
- key 格式设为
"req_" + strconv.FormatInt(time.Now().UnixMilli(), 10) - 设置 TTL =
windowSize，让缓存自动清理过期项 - 每次请求前调用
cache.ItemCount()获取当前存活请求数（⚠️注意：这不是实时精确值，因为ItemCount()是快照，且 GC 可能延迟）
真正可靠的做法是：写入时用 cache.Set(key, struct{}{}, windowSize)，然后手动遍历 keys 并过滤出未过期的（需开启 cache.WithExpirationCheckInterval），但性能差。所以该方案仅适合低频、调试用途。
生产环境推荐：基于 Redis 的滑动窗口
高并发、分布式系统下，本地内存方案必然失效。Redis 的 ZSET 天然适配滑动窗口：用时间戳作 score，请求 ID 或空值作 member。
- 插入：
ZADD rate_limit_key time.Now().UnixMilli() request_id - 清理过期：
ZREMRANGEBYSCORE rate_limit_key 0 (now - windowSize) - 计数：
ZCARD rate_limit_key - 原子执行用 Lua 脚本封装，避免竞态（例如先 ZREMRANGEBYSCORE 再 ZCARD 再 ZADD）
Go 中用 github.com/go-redis/redis/v9 时，务必设置 WithContext 和超时，否则单个慢请求会拖垮整个限流逻辑。另外，ZCARD 返回的是当前集合大小，不是严格意义上的“过去 N 秒请求数”——如果同一秒内大量请求，score 精度不够（需用微秒或纳秒），这时得在应用层做二次去重或改用 RedisTimeSeries。
滑动窗口最难的不是实现，而是时间精度与存储开销的权衡：本地桶方案快但不准，Redis 准但有网络延迟和序列化成本，而真正容易被忽略的是——你是否考虑了服务重启后窗口状态丢失？要不要持久化？这些不在算法里，却决定它能不能上线。
