阿丁的猫滑动窗口这个名字，我在刚接触算法和数据处理的时候觉得它很玄乎，后来做多了才发现，它本质上就是一种防重复计算的思路。你有一串连续的数据，一个可以左右移动的范围，想在这个范围内做统计、做筛选、做最值计算，如果每次都把所有元素重新捋一遍，数据量一大就非常吃亏。滑动窗口就是把“已经算过的结果”用起来，让窗口每次移动时只处理新增和离开的那两个元素，其他结果直接继承。
这篇东西我不会只讲算法题里的那一套。滑动窗口在刷题、工程、信号处理、硬件实现里都有完全不同的用法和侧重点。我会从最基本的原理说起，到双指针解决子串问题，再到单调队列解决滑动窗口最大值这类具体的算法模型，最后扯到工程里很常用的滑动窗口滤波，以及它在DSP、Verilog实现时的一些坑。内容会比较杂，但核心永远是那个窗口思想，以及在不同场景下如何把复杂度打下来。
如果你最近在看《算法》相关的题，或者工作中遇到了时间序列平滑和动态区间的统计问题，这篇文章应该能给你一个比较完整的视角。我尽量说得直接一点，该上代码上代码，该画逻辑画逻辑，不绕弯子。
1. 滑动窗口到底在解决什么
1.1 一个开超市的比喻
先假设你管理一家有20个摄像头监控的仓储走廊，要统计任意连续5分钟通过某个通道的人数。最笨的办法是每分钟把所有画面重新数一遍，但这样做的问题是，相邻两个时间段之间有4分钟的数据是完全一样的，却被反复计算了。
滑动窗口的思路就是，维护一个长度为5分钟的区间，时间每向前走1分钟，窗口的头部加进来1分钟的数据，尾部丢掉1分钟的数据，总量重新计算的时候只处理这个变化的差量，其他4分钟沿用上一次的结果。这个“沿用”的技术就是滑动的精髓，它不是在移动窗口，而是在移动一个计数器的视角。
这不只适用于人数统计，也适用于所有可以做增量计算的场景。所谓的“窗口”，就是一个连续区间；所谓的“滑动”，就是区间的左右边界随着某个指针在数据序列中匀速或变速地向前挪。
1.2 从暴力解法看重复计算的问题
我们拿一个最简单的题目来感受一下：给定一个整数数组和一个数字k，请找出所有长度为k的连续子数组的平均值。
暴力解法非常直观，嵌套两重循环，外层枚举每一个长度为k的子数组的起点，内层把这一段k个数加起来求平均。代码写出来是这样：
python复制def find_averages_bruteforce(arr, k):
result = []
for i in range(len(arr) - k + 1):
total = 0
for j in range(i, i + k):
total += arr[j]
result.append(total / k)
return result
复杂度是O(n*k)，如果数组长度是10万，窗口长度是1万，那就意味着每次计算要做1万次加法，一共要做10万次起点的移动，总计算量是10亿次加法。这个数量级在一般机器上会明显卡顿，几秒到几十秒不等。
但是仔细看就会发现，第一个窗口算完0到9999的和，第二个窗口其实只需要减去arr[0]，再加上arr[10000]，剩余9999个元素一个都不用碰。原来需要1万次操作，现在只需要2次。
python复制def find_averages_sliding(arr, k):
result = []
window_sum = sum(arr[:k])
result.append(window_sum / k)
for i in range(1, len(arr) - k + 1):
window_sum += arr[i + k - 1] - arr[i - 1]
result.append(window_sum / k)
return result
这就是滑动窗口式“去重计算”的核心思想，它的复杂度是O(n)。窗口滑动一次的成本是O(1)，因为你只在对首尾做加减法。这种思路朴素到极致，但它是很多更复杂算法的基础。
1.3 窗口的两种形态：固定和可变
如果你刷过LeetCode或者牛客上的题，滑动窗口经常会演变成两种题目风格。第一种是固定窗口长度，比如刚才那个求平均值，窗口的宽度从头到尾都是k，不会变。解题的时候只需要维护好左右两个指针之间的距离恒定即可。
第二种是可变窗口，长度没有一个给定的固定值，而要靠某种约束条件自己伸缩。比如找到一个子数组，使它的和大于等于某个目标值target，返回这个子数组的最小长度。这种情况下窗口的长度是一个变量，当窗口内元素不满足条件时右指针扩张，满足条件后尝试把左指针往右收缩寻找更短的答案。
可变窗口比固定窗口更考验对“状态”的判断。因为你不能简单地维护一个sum或者max就完事，你需要搞清楚窗口收缩到什么程度时，之前的那个统计量会失效，它用哪种方式重新计算更合理。在很多问题里，这里的统计量不只是一个数字，可能是一个哈希表，一个数组，甚至是一个自定义的频率表。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 双指针与滑动窗口的实现逻辑
2.1 为什么滑动窗口本质上是双指针
从代码层面看，滑动窗口的实现离不开两个索引。定义左边界left和右边界right，初始都在数组起点zero位置。right不断向右扩展，把新元素纳入窗口；当窗口满足某种条件时，left也向右移动，缩小窗口。整个遍历过程中，left和right都不会回头，每个元素至多被访问两次，一次是right经过它，一次是left经过它。
这引出了双指针的核心意义：通过两个单向移动的指针，把暴力枚举O(n²)的可能起点全部压缩成了一次线性扫描。你可能会想，窗口不是连续移动的吗，为什么不会漏掉正确答案？这是因为双指针法依赖一个很重要的前提：窗口的单调性。也就是说，当left向右收缩时，由left和right组合而成的解空间是在有序收窄的，左端越靠右，窗口包含的内容越少，解的长度单调递减，这时你不需要回退left去检查那些已经被证明不可能更优的区间。
2.2 寻找最长无重复子串的通用思路
这个题目估计所有人都遇到过，给定一个字符串，找出其中不含有重复字符的最长子串的长度。它本质上是要维护一个没有重复字符的动态窗口。
思路很简单，右指针逐个读入字符，每当遇到重复字符时，就移动左指针，直到窗口内没有这个重复字符为止。怎么判断有没有重复，用一个哈希表存每个字符在窗口内出现的次数，或者更节省一点，存每个字符最近一次出现的位置。前者简单直观，后者可以做到常数级别的收缩，不过要注意不要把左指针错移到重复字符之前的位置，否则会引入原本应该被排除的字符。
python复制def length_of_longest_substring(s: str) -> int:
last_seen = {}
left = 0
max_len = 0
for right, ch in enumerate(s):
if ch in last_seen and last_seen[ch] >= left:
left = last_seen[ch] + 1
last_seen[ch] = right
max_len = max(max_len, right - left + 1)
return max_len
这里有个细节值得反复提醒：判断重复时不仅需要检查某个字符是否在哈希表中，还要检查它的最近出现位置是否大于等于left。如果它上次出现的位置已经被左指针跳过去了，那这个字符当前就不在窗口内，不算重复。这个陷阱，很多人第一次写都会栽进去，包括我自己，曾经在一个边界case上调试到怀疑人生。
2.3 最短子串问题为什么写法不一样
最长子串问题里，窗口的扩张是主导，收缩是辅助；最短子串问题则刚好反过来。比如给一个字符串s和一个模式串t，要求在s中找一段最短的子串，使得这段子串能覆盖t中所有字符，这就是经典的Minimum Window Substring。
这里需要做两件事来保证效率。一是用一个计数器来记录窗口内还有多少种字符还没有达到要求的数量，当这个计数器为0时说明当前窗口已经是一个可行解。二是每当找到一个可行解，就尝试收缩左指针，把多余的字符踢出去，找到以当前右指针为终点条件下的最短窗口。
python复制from collections import Counter
def min_window(s: str, t: str) -> str:
need = Counter(t)
missing = len(t)
left = 0
result = (0, float('inf'))
for right, ch in enumerate(s):
if need[ch] > 0:
missing -= 1
need[ch] -= 1
while missing == 0:
if right - left < result[1] - result[0]:
result = (left, right)
if need[s[left]] == 0:
missing += 1
need[s[left]] += 1
left += 1
return s[result[0]:result[1]+1] if result[1] != float('inf') else ""
这个代码的巧妙之处在于用计数器的正负判断字符是否为模式串所需。need中初始为t中各字符的出现次数，遍历窗口中的字符时将其减一。当某个字符在窗口里出现的数量不足时，need[ch]会是正数，right扩展时发现正数就递减missing；收缩left时如果发现need[s[left]]为0，说明这个字符被移除后刚好不能满足需求，missing加一，窗口就不可行了，循环退出，继续向右扩展。
这种写法比单纯的哈希表判断快很多，因为missing的变化是O(1)的增量计算，不需要每次重新扫描整个频率表。
2.4 窗口统计信息如何与问题绑定
滑动窗口能不能用，与统计信息是否满足“可减性”密切相关。所谓可减性，就是窗口左端出去一个元素后，你维护的统计量能在O(1)时间内更新，而不是重新遍历剩下的窗口内容。
对于求和、求均值、统计频率这类操作，它们都天然是可减的，因为加法减法本身就是一种可逆运算。对于求最大值、最小值这类操作，如果窗口是动态收缩的，直接靠简单维护一个变量就不可行了，因为当最大值离开窗口后，你并不知道剩下的次大值是多少。这个场景需要换一个数据结构来配合，也就是下面要讲的单调队列。
再举例来说，如果你要维护窗口内的中位数，一个普通滑动窗口的框架是不够的，因为中位数不能靠增量的加减法维护，需要借助有序结构或双堆来重新计算。所以在正式写代码前，先问自己三件事：窗口是固定长度还是可变？统计量是加法可减还是极值型？窗口收缩时统计量能否O(1)更新？三个问题清楚，代码就成功了一半。
3. 单调队列与滑动窗口最值问题
3.1 LeetCode 239题的真实场景
先描述一下问题：给定一个整数数组nums和一个滑动窗口大小k，窗口每次向右移动一位，请输出每个窗口内的最大值。
暴力法自然不必多提，每个窗口重新扫描k个元素，复杂度O(n*k)。这道题用普通滑动窗口和哈希表做不了，因为最大值不像求和那样可以通过加减法逆转。比如说窗口[3, 1, 4, 1, 5]的最大值是5，下一步窗口变成[1, 4, 1, 5, 9]，最大值变成9；但如果变成[1, 4, 1, 3, 2]，原窗口的最大值5已经离开窗口，剩下的最大值是4。你无法从上一个窗口的最大值5推断出这个4，唯一办法是重新比较剩余的k-1个元素。
这时候我们需要一个能在O(1)时间取队首最大值的队列，并且当窗口滑动时，能及时把离开窗口的元素移除，把新进入窗口的元素按顺序插入。很多语言的标准库里的普通queue做不到，因为你需要从队尾弹出比当前元素小的元素，以维持单调性。
3.2 单调队列的原理和数据组织
单调队列，说穿了就是一个普通双端队列，加一条严格的约束：队首到队尾的元素保持严格递减（或非递增）的数值顺序。简单理解，队首永远是当前窗口里最大的元素，后面依次是潜在的候补最大值。队列里存的不是元素的值，而是元素在原始数组里的下标。存下标的好处是非常容易判断某个元素是否已经在窗口之外，只需要比较下标和left指针的关系即可。
当新元素进入窗口时，从队尾往前依次弹出所有小于等于当前元素的下标，因为这些旧元素值更小，又比新元素更早离开窗口，无论从值还是从时间窗口看，它们都不可能在当前及未来的窗口里成为最大值。然后把新元素的下标从队尾插入。这就是所谓的“消除不可能”。窗口向前滑动时，还要检查队首下标是否小于等于left-1，若小于等于则表示它已经不在窗口内，直接弹出队首。
3.3 代码实现与复杂度拆解
下面给出Python的实现：
python复制from collections import deque
def max_sliding_window(nums, k):
q = deque()
result = []
for right, val in enumerate(nums):
# 保持队列单调递减，弹出队尾小于等于当前值的元素
while q and nums[q[-1]] <= val:
q.pop()
q.append(right)
# 队首如果已经离开了窗口范围，弹出
if q[0] <= right - k:
q.popleft()
# 窗口已经形成，记录结果
if right >= k - 1:
result.append(nums[q[0]])
return result
每个元素最多入队一次、出队一次，所以整体时间复杂度O(n)，空间复杂度O(k)（最坏情况下双端队列中存的元素数量不超过窗口大小）。
这里有个细微的优化：先判断队首是否离开窗口，再记录结果。顺序在绝大多数情况下变化不大，但如果你把条件顺序搞反了，有一种极端情况会出错：新元素插入后队列可能刚好只剩它一个，而它恰好在窗口左边界之外。虽然这种情况罕见，但它会暴露你对窗口边界的不敏感。建议大家统一先处理过期元素，再输出结果，逻辑上最清晰。
3.4 单调队列的变式应用
单调队列不只用于最大值，还能用于最小值。把队列的单调性反过来，维护一个递增的队列，队首就是当前窗口的最小值。如果你同时需要最大值和最小值，那就同时维护两个双端队列。
另外，有些问题问的不是窗口内的最值，而是窗口内所有“极值区间”的和之类的组合计数，此时单调队列通常会作为预处理工具，先求出每个元素左侧第一个比它大的位置、右侧第一个比它大的位置，再用数学计数公式推。这种题在面试中属于困难级别，但底层的单调队列思想是相通的。
我自己的经验是，不用死背模板，而是理解单调队列里那一条“排除不可能成为答案的元素”的规则。只要想清楚队列里的元素为什么还有存在价值，这个结构就变得非常顺理成章。它像是一个优等生淘汰机制：新来的成绩更高，排名更后，老的优等生要么成绩不够被淘汰，要么将来比新来的先离开考场，同样没有意义。
4. 滑动窗口滤波：当算法离开刷题平台
4.1 为什么工程里需要滑动窗口滤波
滑动窗口不只在算法题里，工程上更常见的形态叫“滑动窗口滤波”，也叫移动平均滤波，属于信号处理里最基础的低通滤波器之一。
假设你在读取一个温度传感器的数据，原始信号每秒采集一次，结果里会有很多高频噪声，比如随机抖动。你观察数据的长期趋势，希望把它画成一条平滑的曲线，而不是满屏锯齿。简单有效的做法就是取最近N个采样值的平均值作为当前输出。当新数据到来时，窗口向前移动，丢掉最旧的一个值，加入最新一个值。
和算法题里求和优化的思路一致，滤波器也有加速计算的技巧。如果你每次窗口移动都重新把N个数加一遍，当采样频率很高、窗口较长时CPU负担会不小；但如果你维护一个窗口和sum，那么每次只需要sum = sum - 旧值 + 新值，输出就是sum / N。复杂度从O(N)降到O(1)，对嵌入式设备来说非常关键。
4.2 滤波效果的参数调节和边界处理
滑窗平均滤波有一个最直观的参数：窗口长度N。N越大，曲线越平滑，延迟也越大，对真实信号的跟随越迟钝；N越小，跟随越灵敏，但噪声抑制能力变差。实际调试时，你可以用一个阶跃信号来测：给传感器一个突然的温度变化，看滤波后的曲线经过多少个采样周期才能上升到目标值的63%左右。这个时间常数大致等于窗口长度乘以采样周期，正好为你提供了一个调参的标尺。
边界处理是这个滤波器最容易出问题的地方。系统刚启动时，采样值不够N个，此时有两个选择：一是等到攒满N个才开始输出，这会导致最开始的一段时间没有数据，对控制系统并不友好；二是用已有的M个数据做平均，M从1逐渐增加到N，比较平滑，缺点是启动阶段的滤波效果偏弱。实际项目中我更推荐第二种，因为控制环路的带宽需求通常不允许输出长时间断流。
4.3 延迟问题与加权改良
移动平均滤波的代价是信号的延迟，因为输出值本质上是用历史一段时间的数据去平均，对当前信号的响应天然滞后。延迟幅度大约为(N-1)/2个采样周期。
如果不想让延迟那么大，有两条路可以走。第一条路是采用加权移动平均，比如越新的数据权重越高，旧数据逐渐衰减。指数加权移动平均（EWMA）就是其中的一个特例，只用一个权重系数alpha控制新旧数据的占比，不需要维护整个窗口，存储成本极低，非常适合嵌入式实时环境。
第二条路是用滑动窗口做多项式拟合，比如Savitzky-Golay滤波器，它本质上是在每个窗口内做一次最小二乘拟合，用拟合中心点的值替代原始值。这种滤波器在平滑的同时能比较好地保留信号的峰值和谷值，延迟特性也更优秀，但计算复杂度会高一些。
4.4 Verilog和DSP里的滑窗实现要点
如果你做FPGA或者硬件信号处理，滑动窗口滤波也很常见。用Verilog实现一个N点滑窗平均时，最核心的问题是“如何高效地维护最新N个采样值”。
大多数人的第一个想法是用一个数组存N个寄存器，每个时钟周期把所有寄存器整体移位，新采样值写入reg[0]，reg[N-1]的值被丢弃。但这样的写法在N较大时会消耗大量片内寄存器，并且会产生很大的组合逻辑延迟。
更推荐的方案是使用环形缓冲区，或者用FPGA内部的Block RAM作为数据缓存。你维护一个写地址指针和一个读地址指针，写指针每周期写入新采样值，读指针读取的是N个周期前写入的旧值，然后用一个加法器做加减法：sum = sum + new_sample - old_sample。这个结构不会把N个数据全搬到逻辑层，资源消耗与N无关，N只影响存储深度。要注意定点数溢出问题，累加器位宽要预留足够，否则长时间运行后窗口和容易溢出，很多人第一次做硬件滤波时都吃过这个亏。
4.5 滑动窗口在TCP和其他场景里的身影
还有一个你每天都在用的滑动窗口：TCP协议的流量控制。发送方维护一个窗口，表示“未收到确认但已经发送出去的数据包的数量上限”。窗口越大，网络吞吐量越高，但接收方缓冲区压力也越大；如果窗口溢出，网络拥塞随之为零。TCP的拥塞控制本质上也依赖动态调整这个窗口的大小，这和子串问题里的可变窗口有异曲同工之处。只是网络协议里的窗口更复杂，除了接收能力之外，还要考虑丢包率、RTT和拥塞信号。
理解这一层之后你会发现，滑动窗口不是某个数据结构和算法专属的，它是一种通用的资源调度思想，凡是要在一个连续范围上做增量决策的场景都可以套用。
5. 易错点与调试经验：刷题和项目里都得注意的坑
5.1 死循环产生的两个原因
我见过非常多人写可变窗口双指针时出现死循环，问题往往出在两方面。一是while条件写反，左指针移动条件和右指针移动条件搞混。二是跳出内层循环后，忘记重新检查外层的退出条件。
处理这种问题的有效方式是在代码里临时加一个迭代次数保护：声明一个step变量，每次循环step += 1，如果超过某个阈值（例如数组长度乘2），就强制报错退出。跑通后再把保护代码删掉。这种调试方式虽然有点暴力，但是能在几秒内暴露是否死循环，比人眼干瞪代码高效得多。
5.2 边界条件要用极端用例测试
滑动窗口题目中最常见的边界坑包括：数组为空、k等于0、k大于数组长度、数组里全是同一元素、窗口长度为1、数据量很大的递增序列。
以滑动窗口最大值为例，如果你拿一个递减序列去测试，队列总是只有一个元素，因为新元素总比队尾小，不会触发弹出。而如果你拿一个递增序列去测，队列每来一个新元素都要把之前所有元素弹出，最后队列依然只有一个元素。这两种场景下对队首过期判断的处理方式完全相同，但如果你代码里把过期判断放在新元素插入和弹出之后，就有可能在队首刚过期时错误地插入了一个非最大值的元素。
我个人的习惯是一开始就给每个题写一份包含空数组、单元素、全相等、递增序列的测试用例表，让函数逐条跑一遍再开始做优化。不要等到代码写完了再补测试，那样往往只覆盖了你自己记忆中的happy path。
5.3 固定窗口和可变窗口的选用判断
有的题目表面看起来像是求子数组的最值，但读完发现窗口尺寸没有给出来，这个时候第一反应不应该是直接上滑窗，而是先判断题目对子数组长度的要求是什么。如果子数组长度不定，但窗口内需要满足某些数值限制（比如和最接近target、乘积小于k），这时候可变窗口非常合适。
另外还有一种题，它问的是“是否存在某个长度为k的子串包含至少两个重复字符”，这类题其实可以用一个哈希表加固定长度滑动窗口在O(n)内解决，而不是去穷举所有子串。
记住一句话：当最长/最短/是否存在这种问题出现在连续子数组或子串上时，优先考虑双指针滑动窗口；但当子数组本身无连续性要求时，滑动窗口通常是无效的，它只适用于连续区间。
5.4 真实面试中怎么展示滑窗思路
面试里遇到滑动窗口题，关键不是直接闷头写代码，而是先把题目的特征说清楚。我会先讲“这道题要求在一个连续区间上找最优/满足条件的解，区间可以变化，且每次移动时状态更新可以做到O(1)，所以考虑滑动窗口”，然后画一个简单的右指针扩展、左指针收缩的示意图，再开始写码。
写码时把重点放在两个地方：窗口状态（如sum或哈希表）在什么时候更新、为什么更新；窗口是否已经满足条件，以及如何判断。这两点讲清楚了，面试官通常就不会再揪着你的边界case猛问了，因为他能看出你理解了算法本质而不只是背模板。
在项目里使用同理，你需要在代码注释里写明窗口的左右边界定义，定义是“左闭右开”还是“左闭右闭”。这个约定不同，代码里所有边界判断都会不同，如果不统一，维护代码的人很容易把left、right的取值弄错。我在做控制器代码时习惯统一使用“左闭右开”，因为这样窗口长度就是right-left，不需要额外加一，很多判断会更直观。用哪种都行，但一定要统一并注释清楚。
5.5 从算法题到系统优化的一点感悟
滑动窗口这类算法的意义不在于让你记住某个题的答案，而在于培养一种对重复计算的敏感度。每次你看到一段处理连续区间的循环，哪怕没有任何框架提示，也可以先问一下：相邻两次循环的结果之间，能不能复用？
我在实际调优一个高吞吐数据处理模块时，原本需要每秒钟对最近1000条记录求标准差，朴素实现根本顶不住。后来改成滑窗方式，维护窗口内的和与平方和，再用公式标准差 = sqrt((sum_sq - sum*sum/n) / (n-1))，性能直接提升了一个数量级。这个过程没有用到任何高深的数据结构，就是滑动窗口的减法和加法思想，却解决了一个原本看起来属于“高性能计算”才配得上的问题。
6. 滑动窗口的扩展与未来使用边界
滑动窗口的变体能应对的场景越来越多。在时间序列数据库里，滑动聚合是时序查询的一项基础功能，比如“最近5分钟的平均CPU使用率”，很多时序数据库底层就是通过滑动聚合算子和时间桶来实现的。在实时推荐系统里，滑动窗口用于统计用户的短期兴趣，只取最近几次点击行为作为特征输入，而不是全量历史。在监控告警系统中，滑动窗口用于判断某项指标是否在持续异常，比如连续N个采样点超过阈值才触发告警，避免偶发噪声导致的误报。
如果你对算法竞赛比较感兴趣，滑动窗口和二分答案的组合也很常见。比如“是否存在一个长度为k的子数组，其最大值和最小值之差不超过某个阈值”，这类题往往需要先二分枚举k，再用滑动窗口去检查可行性，复杂度从O(n² log n)降为O(n log n)。
在这些应用里，窗口的形态不再只是数组的一个区间，它会变成一堆事件的时间范围、一组消息的数量范围、一个网络连接的速率范围。但核心的那套增量更新的思想始终不变：只在边界变化处做计算，然后把中间状态保住。这很像优秀工程师设计系统时的习惯，尽量复用已经算好的东西，不为重复的工作买单。
我在实际项目中有一个习惯：改动任何一个涉及滑动窗口的代码后，一定要用一种特殊用例来回归测试，那就是“窗口边界上连续出现相同值的元素”。这一个用例能拦住很多隐蔽的边界问题，比如单调队列中新旧元素相等时的去留，还有滑窗平均中旧值和新值恰好相等时sum的符号问题。
刷题软件和工作中使用滑窗还有一个区别。刷题时你完全清楚输入数组大小和范围，可以用更精妙的写法展示技巧。工作中你会遇到无穷无尽的不定长数据流，窗口的边界、数据的异常、计算的溢出都需要额外处理。刷题教给你的是那套“干净”的逻辑，项目实践则是帮你把这套逻辑变得皮实耐用。
从最简单的滑窗求和开始，到双指针子串，再到单调队列、滤波算法，这条线走下来，你基本就掌握了这个思想在不同层次上的运用。如果刚开始觉得理解困难，建议别急着去背各种题型的代码模板，先拿一支笔在纸上把窗口每一步的移动画出来，把left和right每一次的移动原因写清楚。画明白一两道题，再去看其他滑窗题就会有一种豁然开朗的感觉。
我自己当年看滑动窗口最大值那题的题解，看了很多遍都没有真正弄懂为什么队列可以像一个“淘汰赛”一样维护最大值。后来花了一晚上，手动把递增序列和递减序列两种极端情况都画了一遍队列里的变化过程，才算彻底明白。从那以后，无论什么滑窗题，我都会先手动模拟一遍小例子，再写代码。这个小习惯建议你也试一试，它比看一百遍讲解都有用。