go滑动窗口需手动维护left/right索引，用原生切片+显式控制实现轻量可控；关键在right扩展后while收缩left，注意越界、取模精度、并发安全及redis服务端时间一致性。
Go 里没有内置滑动窗口类型，所有滑动窗口算法都得手动维护 left 和 right 两个索引，靠切片截取和条件判断来推进——这不是缺功能，而是 Go 的设计选择：用原生切片 + 显式索引，比封装队列更轻、更可控、零隐藏分配。
滑动窗口子数组问题：怎么维护 left/right 索引不越界
典型场景是找满足某条件的最短/最长连续子数组（如“和 ≥ target 的最短子数组”）。关键不是移动 right，而是每次 right 增加后，要 while 循环收缩 left，直到窗口不满足条件为止。
-
left不能无脑设为lastPos[ch] + 1；必须用max(left, lastPos[ch]+1)，否则可能把 left 拉回已滑过的区域 - 切片截取
s[left:right]是 O(1) 操作，但要注意right最大只能到len(s)，越界 panic 会直接炸掉 - 循环退出条件别写成
left 就完事——得结合业务逻辑判断，比如“窗口和 <li>初始化时 <code>left = 0，right从 0 开始 for-range 或 for-i，别漏掉第一个元素
滑动窗口最大值：为什么不用暴力遍历
暴力法对每个窗口调用 max() 是 O(n×k)，当 k 接近 n 时退化成 O(n²)。真实服务中数组长度常达 10⁵ 级别，暴力根本扛不住。
- 正确做法是用单调递减双端队列（实际用
[]int存下标），保证队首永远是当前窗口最大值对应下标 - 每次
right移动时：先从队尾弹出所有nums[deque[i]] 的下标，再压入 <code>right - 检查队首下标是否
，是则 <code>deque = deque[1:]弹出 - 注意：队列存的是下标，不是值；比较和截取都得通过下标间接访问
nums
滑动窗口限流：为什么 time.Now() 直接删老数据是假滑动
用 time.Now() 判断并删除 map 中“过期时间戳”，本质是固定窗口——它只看绝对时间，不保留历史请求的时间分布，窗口无法滚动叠加。
- 真滑动窗口必须保留最近 N 个时间片的计数，比如 60 秒窗口分 12 片（每片 5 秒），新请求进来时只剔除 >60 秒的片，其余累加
- 并发场景下，直接读写
map[int64]int会触发panic: concurrent map read and map write - 推荐用预分配
[]int64+atomic.AddInt64，索引计算必须用(now.UnixNano() / shardDuration) % int64(shards)，且取模前务必转int64 - 过期判断不能只比索引差，得用绝对时间：
if now.UnixNano() - bucketTimestamp > windowSec*1e9
Redis 实现分布式滑动窗口：为什么 ZSET 比 list 更可靠
用 LPUSH + LTRIM 看似简单，但它只按长度截断，无法按时间范围精准清理——如果请求速率不均，老数据可能滞留远超窗口时长。
- ZSET 的
ZREMRANGEBYSCORE可直接按时间戳范围剔除，配合ZADD和EXPIRE就能闭环 - Lua 脚本里别用客户端传来的
time.Now().Unix()当 score，要用redis.call("TIME")获取 Redis 服务端时间，避免多机时间不同步导致窗口失效 - 脚本返回值是
int64，不是 bool，Go 里要用result.(int64) == 1判断，强转失败会 panic - key 设计建议带业务维度，比如
"rate:ip:192.168.1.100"或"rate:uid:12345"，避免全局限流误伤
最容易被忽略的是时间精度与并发安全的耦合：索引算错一纳秒，整个窗口计数就偏移；原子操作漏一个，多个 goroutine 就会覆盖彼此的计数。滑动窗口看着简单，真正稳住得抠到每一行索引计算和每一次内存访问。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
