滑动窗口计数器不能用map+定时清理，因并发panic、锁争用、时间对齐误差和内存泄漏导致统计不准；应采用环形数组+原子操作实现真滑动，预分配槽位、懒清理、严格整除关系。

滑动窗口计数器不能靠 map + 定时清理凑合，否则任意时刻往前推 N 秒的统计值必然不准——漏掉的时间段不会自己跳出来。

为什么 map[string]int + time.Ticker 不行

看似简单：每秒清一次过期 key，新请求往 map 里塞。但问题扎堆：

• 多个 goroutine 并发写 map 直接 panic：concurrent map read and map write
• 加 sync.RWMutex 后，高并发下锁争用严重，实测 QPS 断崖下跌
• 定时清理是“整点对齐”，比如窗口 60 秒、清理在整秒触发，那 1717023400～1717023449 这 50 秒的请求全被提前删掉，新请求还没来得及归入当前窗口
• time.Now() 作 key 会导致内存持续增长，不清理就 OOM；清理又不准，本质是把滑动窗口降级成了固定窗口

用环形数组 + 原子操作实现低开销真滑动

核心是预分配、免锁、懒清理。推荐结构体字段：slots []uint64、timestamps []int64、slotDur（毫秒）、windowDur（毫秒）。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 数组长度 = windowDur / slotDur，必须整除；例如 60 秒窗口配 1 秒分片 → 长度 60
• 每个 slot 存该时间片内的请求数，用 atomic.AddUint64(&c.slots[i], 1) 更新，禁止直接 c.slots[i]++
• shift() 不在每次 Inc() 里遍历全部 slot，而是只检查当前 slot 是否已过期；过期则归零、更新时间戳、移动索引
• timestamps[c.currentIndex] 必须存该 slot 的起始时间戳（非 now），用于和 now - windowDur 比较判断是否过期
• 并发安全靠 sync.RWMutex 包住 shift() 和索引更新，atomic 管计数，别全锁整个结构体

什么时候该换方案：单机扛不住或要跨实例

纯内存环形数组适合单实例、QPS ≤ 5k 场景。超了或需多实例共享状态，就得换：

• 单机高频（>10k QPS）且维度少：改用分片原子计数器 —— 开 N 个 int64 变量（N ≈ CPU 核心数），按 key 哈希取模写入对应分片，读时遍历求和
• 多实例部署：必须上 Redis + ZSET，用 Lua 脚本保证原子性；ZCOUNT + ZADD + ZREMRANGEBYSCORE 三步不可拆，且所有时间戳必须用 redis.call("TIME") 获取服务端时间，禁用客户端 time.Now()
• 别碰 sync.Map 存时间片 —— 它为读多写少设计，滑动窗口频繁更新+遍历，性能反不如分片 map + 独立 sync.RWMutex

真正难的不是写对逻辑，而是 slotDuration 选多细、windowDur 和 slotDur 整除关系是否严格满足、以及 shift 里时间比较是否用绝对时间戳而非相对索引差——这三个点线上出问题几乎都是静默错，压测不出，只在特定时间点漏统计。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！