滑动窗口遇到负数就失效？前缀和+单调队列来解最小子数组和

我一直觉得，滑动窗口是算法题里最接近“套路”的那一类：右指针往前扩，左指针在条件不满足时跟着缩，来回一两次扫完数组，答案就出来了。直到一道“求最小子数组和”的题把我卡住——注意，不是“和至少为 target 的最短子数组”，而是直接问所有满足长度约束的连续子数组里，和最小是多少。如果数组里全是正数，这套双指针收缩逻辑勉强还能应付；一旦出现负数，窗口向右扩的时候和反而变小，左指针往右缩的时候和反而变大，两根指针瞬间不知道该听谁的。这篇文章就把这条从简单到变难的完整路径走一遍，顺便把这类题真正背后的工具——前缀和加单调队列——讲清楚，适合正在刷题卡壳、或者想在面试里把滑动窗口变体讲出深度的同学。

1. 别被“滑动窗口”四个字骗了：这道题比看起来难在哪

1.1 基础题与进阶题：一字之差，解法完全不同

最常见的滑动窗口入门题是“长度最小的子数组”：给你一个正整数数组，和一个目标值 target，找出满足总和大于等于 target 的长度最小的连续子数组。这题被收录在 LeetCode 209，解法是双指针，左右指针维护一个窗口，右指针不断吞元素，左指针在满足条件时收缩，最终在 O(n) 时间内跑完。

把题目换成“最小子数组和”之后，意思是完全不同的：给定一个整数数组（注意，可以含负数），以及一个长度下界 k，找出所有长度至少为 k 的连续子数组中，和最小的那一个。名字上只是把“最短”换成“最小”，但大多数人把 209 那套模板套过来之后，会发现要么跑不出正确答案，要么压根不敢写。

原因在于：209 能双指针收敛，是因为它的数组是“正整数”，窗口扩展时总和只增不减；而“最小子数组和”这类题目里，数组一旦引入负数，窗口内部的增减方向不受控，你自然没法判断什么时候该缩左边界。

1.2 窗口收缩的前提：单调性

很多人刷滑动窗口题时会忽略一个前提，那就是“窗口和必须具备单调性”。对于正整数数组，右指针每前进一步，窗口总和一定变大；左指针每收缩一次，窗口总和一定变小。这种单调性给了双指针一个明确的方向：

• 总和不够大，就扩右边界；
• 总和已经够大，就缩左边界找最短。

整个过程像一盘有规则的游戏，每一步都有确定可走的路线。可一旦数组里面出现负数，这个规则就没了。加一个负数，窗口和可能下降；去掉一个负数，窗口和反而上涨。方向不确定，指针的收缩逻辑也就没有依据。

记住这一点特别关键。很多人不是不会写双指针，而是不知道双指针为什么能这么写。理解了单调性，你才能真正理解滑动窗口的适用范围，也才能理解后面“前缀和+单调队列”这套解法为什么能绕过单调性的限制。

2. 先热身：正整数场景下，最小子数组和怎么用滑动窗口做

2.1 从“最短长度”到“最小和”的转换

先看一个相对简单的热身题：正整数数组，长度至少为 k，求所有满足条件的连续子数组里，和的最小值。比如 nums = [3, 2, 5, 1, 4]，k = 3，那长度为 3 的窗口有：

• [3, 2, 5] 的和是 10
• [2, 5, 1] 的和是 8
• [5, 1, 4] 的和是 10

最小是 8，对应的子数组是 [2, 5, 1]。

由于数组全是正数，长度越长，窗口和越大，所以“长度至少为 k”在求最小值的时候，其实等价于“长度恰好为 k”。这是一个很关键的简化：我们只需要把一个固定长度为 k 的窗口从数组左端滑到右端，每滑动一步，窗口的组成就发生变化，记录过程中的最小和即可。

这种固定长度的滑动窗口，代码非常简单：

python复制def min_subarray_sum_fixed_k(nums: list[int], k: int) -> int:
    if not nums or k <= 0 or k > len(nums):
        return 0

    cur = sum(nums[:k])
    ans = cur

    for right in range(k, len(nums)):
        cur += nums[right] - nums[right - k]
        ans = min(ans, cur)

    return ans

2.2 滑动窗口增量更新的本质

这段代码的核心只有一行：cur += nums[right] - nums[right - k]。它的意思是：窗口右移一格，就把新进来的元素加进去，把滑出去的元素减掉，不需要重新把窗口里所有元素求和一次。这个“增量更新”的思路，是滑动窗口类题目能在 O(n) 时间内跑完的根本原因。

可以对比一下暴力方案：如果对每个窗口都重新求和，时间复杂度是 O(n × k)，当 k 接近 n/2 时接近 O(n²)，明显不可接受。滑动窗口把每个元素进入窗口和离开窗口的代价都摊到 O(1)，于是整个过程是 O(n)。

等后面遇到更复杂的“至少 k”问题，你会发现我们依然要维护一个滑动的候选集合，只是集合里存的不是数字，而是下标，而且求的也不是“窗口内元素和的最小值”，而是“窗口内前缀和的最大值”。增量更新的思想会一直在。

3. 负数入场：为什么双指针模型瞬间失效

3.1 一个“看着能滑，其实不能滑”的反例

假设数组是 [-1, 5, -1]，k = 2。我们来手算长度至少为 2 的所有连续子数组：

• 长度 2：[ -1, 5 ] 的和是 4，[ 5, -1 ] 的和是 4
• 长度 3：[ -1, 5, -1 ] 的和是 3

最小和是 3，出现在长度 3 的整个数组里。

但如果你用“长度恰好为 2 的固定窗口”去滑，得到的最小值是 4，正确答案会被漏掉。原因就是负数存在时，“长度越长和越大”的假设不成立了。多取一个 -1，窗口和反而从 4 降到 3。

再想用双指针的“收缩”逻辑：假设我们试图维护窗口和，感觉窗口和太小时就缩左边界。可在这个例子里，[ -1, 5 ] 的和是 4，如果把右指针扩到 -1，窗口变成 [ -1, 5, -1 ]，和是 3，更小了。到底该扩还是该缩？你找不到一个统一的规则。

3.2 失效的本质：窗口和的单调性被破坏

前面说过，双指针滑动窗口的正确性依赖单调性：右指针扩展，窗口和一定变大；左指针收缩，窗口和一定变小。一旦数组中出现负数：

• 右指针扩展可能让窗口和变小（加入负数）；
• 左指针收缩可能让窗口和变大（去掉负数）。

整个窗口的和不再是一个关于“大小”的单调函数，所以想用“当前窗口和与目标值比较”来决定指针移动方向，就完全行不通了。

这也是为什么面试官一旦把题目从“正整数”改成“整数数组”，难度会直接上一个台阶。因为你不能照搬模板，必须重新设计一套能在非单调环境下维护窗口信息的方法。

这里要转变一个思维：我们不再直接维护“原始数组的窗口和”，而是先算前缀和，让问题变成一个等价、但可以在单调结构上处理的问题。这就是接下来要讲的解法。

4. 更难的题：长度至少为 k 的最小连续子数组和

4.1 题目定义与输入输出约定

先把题目固定下来，方便后面讨论：

给定整数数组 nums（允许负数），以及一个正整数 k，返回所有长度至少为 k 的连续子数组中，和的最小值。

例如：

text复制输入: nums = [1, -2, 3, 5, -3, 2], k = 3
输出: 2

因为所有长度至少为 3 的子数组里，[1, -2, 3] 的和是 2，这就是最小和。

我先说结论：这题正确解法是“前缀和 + 单调队列”，时间复杂度 O(n)，空间复杂度 O(n)。接下来一步步拆。

4.2 前缀和一到手，滑窗问题变成滑“前缀和”问题

定义前缀和 pre[i] 表示数组前 i 个元素的和：

text复制pre[0] = 0
pre[i] = nums[0] + nums[1] + ... + nums[i-1]

那么区间 [l, r) 的和就是：

text复制sum(l, r) = pre[r] - pre[l]

题目要求长度至少为 k，也就是：

text复制r - l >= k

其中 l 是子数组的左边界下标，r 是右边界下标。

现在固定一个右端点 r，那么和的公式是 pre[r] - pre[l]。在 r 固定的情况下，pre[r] 是一个常数，想让整个式子最小，就需要让 pre[l] 最大。

同时 l 的取值范围受到长度约束：

text复制0 <= l <= r - k

也就是说，对于每一个右端点 r，我们要在 l ∈ [0, r-k] 这个范围内，找一个能让 pre[l] 最大的位置。这个“候选 l 的集合”会随着 r 增加整体右移，本质上就是一个滑动窗口。

4.3 单调队列怎么维护“窗口内最大前缀和”

既然要在滑动窗口里维护最大值，自然想到单调队列。

我们需要一个双端队列，队列里存的是下标，下标对应的 pre 值从队头到队尾严格递减。这样队头始终是当前候选集合里 pre 最大的那个下标。

每次右端点 r 移动一步，会新增一个候选下标 l = r - k。假设我们要把它加入队列，需要先弹出队尾那些 pre 值比它小的下标，因为那些下标既没有它“大”，位置又更靠左，后续随着 r 继续增大，只能更早过期，不可能成为最优选择。

弹出操作完成后，把 l 从队尾入队。此时队头就是当前候选集合里 pre 最大的下标，对应的就是“以 r 为右端点时，能使子数组和最小的左端点”。

代码实现如下：

python复制from collections import deque

def min_subarray_sum_at_least_k(nums: list[int], k: int) -> int:
    n = len(nums)
    if not nums or k <= 0 or k > n:
        return 0

    pre = [0] * (n + 1)
    for i in range(1, n + 1):
        pre[i] = pre[i - 1] + nums[i - 1]

    q = deque()
    ans = float('inf')

    for r in range(k, n + 1):
        candidate = r - k
        while q and pre[q[-1]] <= pre[candidate]:
            q.pop()
        q.append(candidate)

        # 队列中所有下标天然满足 <= r-k 的条件，所以不需要额外淘汰过期元素
        ans = min(ans, pre[r] - pre[q[0]])

    return ans

代码非常短，但每一行都值得细看。尤其要注意的是：r 的枚举范围是从 k 到 n，因为只有当右端点至少有 k 个前缀元素时，才可能存在长度至少为 k 的子数组。

4.4 用一个具体例子走查过程

我们拿 nums = [1, -2, 3, 5, -3, 2]，k = 3 来走一遍。

先算前缀和：

text复制pre = [0, 1, -1, 2, 7, 4, 6]

• r = 3，候选 l = 0，pre[0] = 0，队列变成 [0]，ans = pre[3] - pre[0] = 2 - 0 = 2；
• r = 4，候选 l = 1，pre[1] = 1，队尾 pre[0] = 0 <= 1，弹出 0，队列变成 [1]，ans = pre[4] - pre[1] = 7 - 1 = 6，仍取 2；
• r = 5，候选 l = 2，pre[2] = -1，队尾 pre[1] = 1 大于 -1，不弹，队列变成 [1, 2]，ans = pre[5] - pre[1] = 4 - 1 = 3，仍取 2；
• r = 6，候选 l = 3，pre[3] = 2，队尾 pre[2] = -1 <= 2，弹出 2，队尾 pre[1] = 1 <= 2，弹出 1，队列变成 [3]，ans = pre[6] - pre[3] = 6 - 2 = 4，仍取 2。

最终结果是 2，和手算一致。

注意这里有个小细节：为什么队列不需要“过期淘汰”逻辑？因为在本题的“至少为 k”约束下，l 的范围是 [0, r-k]，而每个候选下标加入队列时，刚好满足 l <= r-k，之后 r 变大，条件只会越来越宽松。换句话说，所有进入队列的下标都永远不会变成非法下标。这一点和“长度恰好为 k”或者“长度在 [k, m] 之间”这类题不同，后者才需要显式判断队头下标是否小于 r-m。

4.5 为什么这段逻辑等价于“滑动窗口求最小值”

现在回头看，这道题其实把滑动窗口的对象从“原始数组的窗口”换成了“前缀和候选下标的窗口”。窗口每移动一次，要做的事就是：

1. 新增一个候选下标；
2. 用单调队列维护窗口内的最大值；
3. 用当前右端点对应的前缀和减去窗口内最大前缀和，得到一个候选答案。

这就是为什么这道题可以被归到“滑动窗口”这个大类下，但如果你只会双指针套模板，就会卡住。它真正的难点在于识别出：需要被滑动和维护的不是窗口本身的和，而是前缀和的最大值。

5. 这道题我踩过的四个坑

5.1 坑一：前缀和数组的索引偏移

前缀和我习惯开成 n+1 长度，pre[i] 表示前 i 个元素的和。这样做的好处是 pre[0] = 0 可以作为空数组的前缀和，方便处理“子数组从下标 0 开始”的情况。但代价是索引很容易乱：nums[i-1] 对应 pre[i]，区间 [l, r) 的和是 pre[r] - pre[l]。

我一开始写的时候习惯从 1 到 n 枚举 r，结果计算子数组右边界时经常往右偏一格，导致漏算整个数组。后来总结了一个方法：每次都先在纸上画一条下标轴，把 nums 的下标和 pre 的下标标记清楚，再写代码，基本不会再错。

5.2 坑二：ans 的初始值

求最小值时，ans 一般初始化为 float('inf')，这没问题。但要注意处理无解的情况，比如 k 大于数组长度。如果不提前判断，直接进入 for 循环，最后返回 float('inf')，调用方很可能以为这是合法结果，从而埋下隐患。遇到这种情况我习惯返回 0，并且把题目约定写清楚：无解时返回 0。

另外，别用 0 作为 ans 的初始值。如果题目所有合法子数组和都大于 0，你会得到一个错误的 0。这个错误在测试用例不够多的时候很难发现，因为正数用例能过，负数用例才暴露。

5.3 坑三：队列里存下标而不是存值

单调队列存的是候选下标的索引，不是 pre 值本身。原因至少有两个：

1. 我们需要知道这个下标对应的 pre 值，可以直接通过 pre[q[i]] 拿到；
2. 后续如果题目增加窗口长度上限，需要根据下标判断是否过期，只存值就没法判断。

哪怕当前版本题目用不到过期判断，我也建议一律存下标。这是一种防御性写法，也能让代码的意图更清楚：队列管理的是“候选位置”，不是“候选数值”。

5.4 坑四：弹出条件里用 <= 还是 < 的细节

在维护递减队列时，如果新候选的 pre 值等于队尾的 pre 值，要不要弹出队尾？

• 用 <= 弹出，会保留更靠右的候选下标；
• 用 < 不弹出，会保留更靠左的候选下标。

在当前题目里，由于我们只求最小和，不关心具体是哪个子数组，两者结果一样。但如果你后续要输出“最左边的满足条件的子数组”，用 < 保留更早的下标更方便。我在面试里被追问过这个细节，当时没多想，后来总结出这样一条经验：默认写成弹出 < 的严格版本，需要最值下标时就不会再回来改。

对比一下不同写法的差异：

这点看起来小，但在面试手写代码的场合，主动提一句“这个细节取决于要不要输出下标”，能明显加分。

6. 从刷题到落地：滑动窗口思想在工程里的三种打开方式

很多同学刷完题觉得算法题和工程是两码事，其实滑动窗口这类结构在实际系统里到处都是。尤其是热词里出现的“滑动窗口滤波”和“流量控制（滑动窗口）”，背后都是同一个一进一出的窗口模型。

6.1 滑动窗口限流：窗口里装的是时间戳

接口限流里有一种常见做法：滑动窗口计数。比如限制每个用户每分钟最多 100 次请求，我们维护一个窗口，窗口里存的是请求时间戳。每个新请求进来，先移除掉窗口外（大于 60 秒前）的时间戳，再看窗口内数量是否达到上限。

这个逻辑和滑动窗口求和几乎一模一样：窗口右移一个新数据，左侧过期数据删除，窗口内统计一次。只是统计的不是数值和，而是请求个数。但它同样依赖“一进一出，增量维护”的思想，没有窗口思维的人通常会写一个暴力循环，每次遍历最近所有请求，性能就差很多。

6.2 TCP 流量控制：窗口大小本身就是动态调整的

网络协议里的滑动窗口也是经典案例。TCP 里有两个核心窗口：接收方通告的接收窗口 rwnd，以及发送方根据网络拥塞程度维护的拥塞窗口 cwnd。实际的发送窗口取两者的较小值。慢启动、拥塞避免、快重传、快恢复这些机制，本质上都是在动态调整 cwnd 这个“窗口上限”。

这跟双指针滑动窗口的收缩扩张逻辑非常像：窗口大小不是固定的，而是根据当前状态决定是扩大发送量，还是收缩发送量。区别只是算法题里窗口的扩张收缩由数组条件驱动，网络里由确认包和丢包事件驱动。把窗口理解成一个“状态区间”，很多问题就能横向打通。

6.3 滑动窗口滤波：每一帧都在做“窗口内求值”

嵌入式或信号处理里常见的滑动平均滤波器，就是维护一个长度为 N 的窗口，每个采样点进来，窗口右移一位，输出窗口内数据的平均值。实现上通常就是一个累加器：新数据加进来，旧数据减掉，再做一次除法得到均值。

这个“求和”模式和固定长度窗口的最小和问题完全一致。如果你在实时数据流上不仅想看平均值，还想看窗口内最小值，那就要在窗口内维护一个单调队列，和本文第 4 节的解法一脉相承。

热词里有“滑动窗口滤波器延迟”，这个延迟其实就是窗口长度 N 导致的：窗口越长，平滑效果越好，但对突然变化的响应越慢。这是工程里的权衡，也是为什么有时要使用最小值、最大值这类聚合指标，而不只是平均值。

6.4 监控指标里的滚动最小和

再举一个我工作中实际遇到的场景：监控系统需要检测某个服务的调用量“持续下滑”时段。如果只看单点波动，噪音很大；如果看连续一段时间的累积变化，更容易发现趋势性问题。

这时就可以定义：给定一个调用量序列，找出长度至少为 k 的连续时间段里，调用量总和最小的那一段。调用量虽然一般不是负数，但趋势检测的核心算法和本文的进阶题完全一致。你用前缀和加单调队列跑一遍，就能在线性时间内定位“跌得最狠的一段时间”，而不是用 O(n × k) 的暴力窗口去慢慢滑。

我自己的体会是，刷题刷到滑动窗口，不应该满足于把 209 的模板背下来。真正有用的，是理解窗口的“单调性依赖”和“一进一出的增量维护”这两个底层思想。把这两点吃透，再遇到负数数组、长度约束、甚至流量控制、滤波算法，你都能迅速认出那层“滑动窗口”的骨架，换一层皮就能用。