不能直接用 atomic.AddInt64 实现滑动窗口限流，因为它缺乏时间维度和生命周期管理能力，无法自动清理过期窗口，强行使用会导致计数漂移、边界错乱及高并发下误差放大。
为什么不能直接用 atomic.AddInt64 实现滑动窗口限流
因为原子操作本身不带时间维度——atomic.AddInt64 只能增减一个整数，无法自动清理“过期”的请求数。滑动窗口的核心是按时间分片统计、并随时间推移丢弃旧窗口，而纯原子变量没有生命周期管理能力。强行用单个原子变量模拟窗口，会导致计数漂移、窗口边界错乱，尤其在高并发下误差会快速放大。
用 sync.Map + atomic 组合维护时间分片窗口
典型做法是把时间切分为固定长度的 slot（比如 100ms 一个 slot），每个 slot 对应一个 int64 计数器，用 sync.Map 存储：key = timestamp / slotSize，value = *int64。实际更新时：
- 先算出当前 slot key：
slot := time.Now().UnixMilli() / 100 - 用
sync.Map.LoadOrStore获取或新建该 slot 的原子计数器 - 对返回的
*int64调用atomic.AddInt64累加 - 检查总和是否超限：遍历最近 N 个 slot（如最近 10 个 100ms → 1 秒窗口），用
atomic.LoadInt64累加它们的值
注意：sync.Map 不保证遍历一致性，所以「最近 N 个 slot」必须显式构造 key 列表再逐个 Load，不能依赖 Range。
time.Now() 在高并发下可能被调度延迟，影响 slot 判断
Linux 下 time.Now() 底层调用 clock_gettime(CLOCK_MONOTONIC)，通常足够快，但若 Goroutine 被抢占较久（比如在系统调用中阻塞），拿到的时间戳可能比真实 wall clock 晚几毫秒，导致本该归入前一个 slot 的请求被分到下一个 slot，造成窗口内计数偏低、限流变松。
立即学习“go语言免费学习笔记（深入）”；
缓解方式：
- 用
runtime.nanotime()替代time.Now()做 slot 计算（它更轻量，且单调递增） - slot key 计算改用：
slot := runtime.Nanotime() / (100 * 1e6)（100ms = 100_000_000 ns） - 但注意：
runtime.nanotime()返回纳秒级绝对值，不能直接转为可读时间，仅用于相对偏移计算
窗口清理不及时会导致内存泄漏
sync.Map 不会自动删除过期 slot，旧 key 会一直存在。如果每秒生成 10 个 slot，运行一小时就积累 36000 个条目。虽然 Go runtime 有 GC，但大量无用键仍拖慢 Load 和 Range 性能。
必须主动清理：
- 启动一个后台 goroutine，每隔 2–3 倍窗口长度（比如窗口 1s，每 3s 清理一次）
- 计算「最早保留 slot」：
minSlot := (now.UnixMilli() / 100) - windowSlots + 1 - 遍历
sync.Map，对每个 key 转成 int64 后比较，小于minSlot就Delete - 避免在清理时锁整个 map，用
Range配合条件删除即可
真正难处理的是并发清理和写入冲突——sync.Map.Delete 是线程安全的，但清理 goroutine 和请求 goroutine 可能同时操作同一 key，只要不依赖 delete 后立即不可见，就没问题；Go 的 sync.Map 允许这种竞态。
