lloydsheng这道题我刷的时候标记的是“耗时100”，意思是前后加起来差不多琢磨了100分钟才算彻底通透。老实说，LeetCode 1052（Grumpy Bookstore Owner 爱生气的书店老板）的难度标的是 Medium，但它不像那种纯考模板的题，而是把一个非常典型的滑动窗口场景，藏在了一个“老板会生气”的故事里。如果你直接去硬模拟每一种可能，很容易绕进 O(n²) 的坑里出不来；可一旦想明白“窗口里到底该统计什么”，代码又短得让人怀疑是不是漏了条件。
这篇文章我就按自己的思考路径来写：先还原题目场景，再讲暴力解为什么可行但不够好，接着推导滑动窗口的核心思路，最后把边界条件、细节坑点、以及这一类题在 LeetCode 热门 100 题体系里的位置都捋一遍。不管你是刚开始刷题的新手，还是想快速过一遍经典滑窗思路的老手，这篇都能给你一些直接能用的东西。
1. 这道题的场景到底在说什么
1.1 故事背景与数据含义
题目给了你一个书店老板，他有一个“情绪开关”——grumpy 数组。如果某分钟 grumpy[i] = 1，说明老板这一分钟在生气；如果 grumpy[i] = 0，说明他这一分钟心情正常。与此同时，customers[i] 表示第 i 分钟进店的顾客数。
顾客满不满意度是这样算的：老板生气的那一分钟，进来的顾客会觉得服务体验差，不满意；老板不生气的那一分钟，顾客满意。这里有个很关键的前提：顾客是每分钟来一批，而且在老板生气的时候，这些顾客虽然不满意，但并不会直接走掉——他们还是会在店里消费，只是“满意值”不算数了。
然后老板掌握了一个“情绪管理技巧”：他可以选择连续 X 分钟（题目里叫 minutes）克制自己不生气。这 X 分钟里，哪怕 grumpy[i] 原本是 1，也会因为这波克制而变成“不生气”，从而让这一分钟的顾客全部变成满意。
好，那把故事翻译成代码逻辑，其实就是：有一个长度为 n 的数组，我们要选一段长度固定为 X 的连续区间，让区间内原本因为老板生气而不满意的那些顾客，统统变成满意。最终目标是让整天的“满意顾客总数”最大化。
1.2 为什么这道题容易让人想复杂
我第一次做的时候，第一反应是：我是不是要考虑窗口放在哪里，窗口内的 customers 要重新计算，窗口外要按原样计算？这个想法没有错，但它会引导你写出暴力枚举所有窗口位置的代码，而暴力枚举就意味着 O(n * X) 的复杂度。
还有一个更容易踩的迷惑点：窗口选中的那一段，老板“不生气”了，但窗口外面老板该生气还是生气。也就是说，窗口内的 grumpy 相当于被“全覆盖成 0”了；窗口外保持原样。这就在提示我们，问题可以被拆成两部分：一部分是“老板本来就不生气”的固定满意值，另一部分是“窗口能把多少原本不满意的顾客捞回来”。
理解到这一层，你才算把这个题从“模拟题”上升到“优化题”。后面所有的高效解法，都是从这两个部分的拆分出发的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 暴力解法：先想清楚再谈优化
2.1 直接枚举窗口起点
不急着上滑动窗口，先写一版最容易想到的暴力做法，它能帮我们验证对题意的理解是否正确。思路非常简单：枚举所有可能的窗口起点 start，窗口范围是 [start, start + minutes - 1]。然后遍历整个数组，判断第 i 分钟是否计入满意值：
- 如果
grumpy[i] == 0，不管在不在窗口里，这一分钟的顾客都满意； - 如果
grumpy[i] == 1，只有当第 i 分钟落在窗口内，才因为老板克制而变成满意。
写成代码就是这样：
python复制class Solution:
def maxSatisfied(self, customers: List[int], grumpy: List[int], minutes: int) -> int:
n = len(customers)
best = 0
for start in range(n - minutes + 1):
cur = 0
for i in range(n):
if grumpy[i] == 0 or (start <= i < start + minutes):
cur += customers[i]
best = max(best, cur)
return best
2.2 暴力解的时间复杂度分析
这版代码的时间复杂度是 O(n * minutes)，最坏情况下 minutes 接近 n，整体就是 O(n²)。空间复杂度是 O(1)，因为我们连额外数组都没开。
O(n²) 在 n 比较小的时候问题不大，LeetCode 这个题目的约束我没记错的话是 n <= 20000，一旦 n 上了万，O(n²) 基本就要超时了。但我觉得暴力解不是白写，它的价值在于把“窗口内老板生气顾客的贡献”这个核心变量暴露了出来。你会发现，每次窗口移动一步时，只有两个位置发生了变化：左边滑出的那一分钟，和右边新滑入的那一分钟。其他 n-2 个位置完全没变。
也就是说，我们重复计算了大量相同的值。滑动窗口的本质，就是把这种重复计算省掉，用 O(1) 的时间完成一次窗口移动的更新。
3. 滑动窗口核心推导与最终代码
3.1 把满意值拆成“基础值 + 增量”
想明白暴力解之后，下一步就是做数学上的拆分。我们把一整天的满意顾客数写成两个部分：
- 基础值
base：所有grumpy[i] == 0的分钟，无论窗口怎么移动，这些顾客本来就满意，所以它们一定会被计入最终答案。 - 增量
extra：一个长度为minutes的窗口，能额外“拯救”的顾客数量。这些顾客所在的分钟原本grumpy[i] == 1，但因为窗口覆盖，老板在这一段不生气，所以他们从不满意变成满意。
因此，最终答案就是：
code复制answer = base + max(extra)
max(extra) 的意思是：我们要在所有长度为 minutes 的窗口里，找出一个窗口，使得窗口内“老板原本生气的那些顾客数之和”最大。
这一步是整个题目最关键的思维跳跃。一旦你接受了“只需要关心 grumpy 为 1 的位置”，问题就从二维的模拟变成了一维的“在数组上找一个固定长度的连续子数组，使其和最大”。
3.2 滑动窗口的代码实现
有了上面的拆分，代码就非常清晰了。我们分三步走：
第一步，计算 base：
python复制base = 0
for i in range(n):
if grumpy[i] == 0:
base += customers[i]
第二步，初始化第一个窗口的 extra。假设窗口从下标 0 开始，覆盖 [0, minutes - 1]，我们把这段区间内 grumpy[i] == 1 的 customers[i] 加起来：
python复制extra = 0
for i in range(minutes):
if grumpy[i] == 1:
extra += customers[i]
第三步，窗口向右滑动，每次移动一步。滑入的新位置是 i，滑出的旧位置是 i - minutes。我们只处理这两个位置：
python复制best = extra
for i in range(minutes, n):
# 滑入
if grumpy[i] == 1:
extra += customers[i]
# 滑出
if grumpy[i - minutes] == 1:
extra -= customers[i - minutes]
if extra > best:
best = extra
最后返回 base + best 即可。
完整代码长这样：
python复制class Solution:
def maxSatisfied(self, customers: List[int], grumpy: List[int], minutes: int) -> int:
n = len(customers)
base = 0
for i in range(n):
if grumpy[i] == 0:
base += customers[i]
extra = 0
for i in range(minutes):
if grumpy[i] == 1:
extra += customers[i]
best = extra
for i in range(minutes, n):
if grumpy[i] == 1:
extra += customers[i]
if grumpy[i - minutes] == 1:
extra -= customers[i - minutes]
best = max(best, extra)
return base + best
3.3 为什么这里用的是“固定窗口”而不是“双指针收缩”
经常刷题的朋友可能会惯性想到双指针。这题确实可以归类到“定长滑动窗口”这一子类型，它和“最长无重复子串”那种“可变长窗口”的核心区别在于：窗口长度是题目固定好的 minutes，你不能为了让 extra 变大就随意伸缩窗口。因为老板的技巧时间固定，窗口短了浪费技能，长了又不符合题意。
所以，这题用的是最朴素的定长滑动：初始化一个长度为 minutes 的窗口，然后每次整体右移一格。不需要 while 循环去收缩左边界，左右边界同步前进即可。
我把定长滑窗和可变长滑窗的区别列一下，方便你对比：
| 维度 | 定长滑动窗口（本题） | 可变长滑动窗口（如无重复字符最长子串） |
|---|---|---|
| 窗口长度 | 固定为 minutes | 动态变化 |
| 左边界移动方式 | 每次右移一格，与右边界同步 | 根据条件不断收缩 |
| 更新逻辑 | 加右侧新元素，减左侧旧元素 | 移动左边界直到满足条件 |
| 典型场景 | 固定时间/长度的最优连续段 | 最长/最短满足条件的连续段 |
这个区分很重要。很多人一看到滑动窗口就想着用两个指针，结果把固定窗口写成了可变窗口，反而复杂度上去了，逻辑也变乱了。
4. 前缀和写法、边界条件与复杂度对比
4.1 另一种常见写法：前缀和
除了滑窗维护增量，还可以用前缀和来快速求任意窗口内“老板生气顾客数之和”。思路是：先预处理一个数组 prefix，prefix[i] 表示前 i 分钟里，老板生气时进来的顾客总数。这样，窗口 [l, r] 内的生气顾客数就能用 prefix[r+1] - prefix[l] 在 O(1) 时间内拿到。
代码实现是这样的：
python复制class Solution:
def maxSatisfied(self, customers: List[int], grumpy: List[int], minutes: int) -> int:
n = len(customers)
base = 0
prefix = [0] * (n + 1)
for i in range(1, n + 1):
idx = i - 1
if grumpy[idx] == 0:
base += customers[idx]
# prefix 里只累加 grumpy == 1 的顾客数
prefix[i] = prefix[i - 1] + (customers[idx] if grumpy[idx] == 1 else 0)
best = 0
# 枚举窗口右端点，或者枚举窗口左端点都行
for i in range(n - minutes + 1):
l = i
r = i + minutes - 1
extra = prefix[r + 1] - prefix[l]
best = max(best, extra)
return base + best
这种写法的好处是逻辑更直白，不需要手动维护窗口滑入滑出时的增减，适合在面试时先讲思路再写代码，不容易手滑写错。代价是多开了一个 O(n) 的数组，空间上比滑动窗口稍微多一点。两种方案都能过，面试时选你最有把握的那种就行，我个人的习惯是：如果题目明确要求 O(1) 额外空间，就用滑动窗口；如果没有明确要求，前缀和写起来更不容易出错。
4.2 边界条件和隐蔽的坑
这道题虽然代码短，但边界条件藏了好几个，稍不注意就容易翻车。
第一个坑是 minutes >= n 的情况。如果老板的技能持续时间比营业时间还长，那说明整个营业期间他都能克制自己不生气，答案就是所有顾客数之和。我的滑动窗口写法里，初始化 extra 时循环 for i in range(minutes)，如果 minutes > n 会越界访问数组，直接报错。
处理方式有两种：要么在开头加一个判断，if minutes >= n: return sum(customers)；要么用 min(minutes, n) 作为初始化窗口的长度。从严谨性来说，我建议显式处理，别让代码依赖“题目恰好不会出现这种情况”的侥幸心理。
第二个坑是 grumpy[i] == 1 时 customers[i] 为 0 的情况。这种情况不会影响算法正确性，但如果你用“窗口长度等于顾客数之和”之类的直觉去检查，可能会误以为自己算错了。记住，我们统计的是顾客数，不是分钟数。
第三个坑是滑动窗口更新时的顺序。先加滑入的，再减滑出的，这个顺序在本题中无所谓，因为两个位置不会重叠（除非 minutes = 0，但题目里 minutes 应该大于 0）。不过为了保险起见，我会把窗口初始化和滑动循环写得清晰一点，避免在边界临界点上产生歧义。
4.3 复杂度对比表格
| 解法 | 时间复杂度 | 空间复杂度 | 适用场景 |
|---|---|---|---|
| 暴力枚举 | O(n * minutes) | O(1) | n 很小，验证思路 |
| 滑动窗口 | O(n) | O(1) | 最优解，推荐 |
| 前缀和 | O(n) | O(n) | 代码直观，面试友好 |
从 LeetCode 的评分和公司面试频率来看，滑动窗口解法就是这道题的标准答案。它能跑出 O(n) 的时间复杂度，同时保持 O(1) 的额外空间，这种“时间换空间”或“空间换时间”的取舍，在 LeetCode 热门 100 题里反复出现。比如同为滑动窗口家族的 LeetCode 3（无重复字符的最长子串），以及前缀和优化的 LeetCode 560（和为 K 的子数组），思路都是一脉相承的。
5. 常见坑点、调试技巧与题目家族联想
5.1 我在第一次提交时踩过的坑
我这道题第一次提交就吃了一次 Wrong Answer，问题出在我把窗口滑动的起点写错了。我当时写的是：
python复制for i in range(minutes, n):
if grumpy[i] == 1:
extra += customers[i]
if grumpy[i - minutes] == 1:
extra -= customers[i - minutes]
逻辑看起来没错，但我在初始化 extra 时，写成了统计“窗口内所有顾客数之和”，而不是“窗口内老板生气的顾客数之和”。这导致 base 和 extra 出现了重叠计算，最终答案偏大。
这个错误很有代表性：滑动窗口里到底该维护什么统计量，一开始就得想清楚。本题的统计量是“原本生气、被窗口拯救的顾客数”，而不是“窗口内所有顾客数”。如果你把后者放进去，窗口外正常的顾客算了一次，窗口内满意的顾客又算了一次，等于重复计数。
所以调试时我总结出了一个土办法：构造一个极简例子，比如 customers = [1, 2, 3]，grumpy = [1, 0, 1]，minutes = 1。手算一下答案应该是多少，再跑代码比对。这种小规模测试用例在本地一分钟就能验证，远比你盯着屏幕干瞪眼效率高。
5.2 线段树、差分数组能不能做
有人可能会问，这题能不能用更高级的数据结构，比如线段树或者差分数组。答案是能，但没必要。线段树适合处理区间查询和区间修改，而这里的区间是固定长度、只查一次最大值，用线段树属于杀鸡用牛刀，代码复杂度高，常数也大。差分数组适合处理区间增减的多次操作，但本题没有多次区间修改的需求。
在 LeetCode 周赛和热门 100 题里，固定长度窗口的问题是最基础的模板题，它考察的是你能不能把一个看似“全局最优化”的问题，转化成“局部窗口最优化”的问题。这种转化能力比会写某一种数据结构重要得多。你去看 LeetCode 1273（删除树节点）、LeetCode 073（爱吃香蕉的狒狒）这些题，它们虽然分属树形 DP 和二分答案，但核心都是同一个思路：先分析问题的单调性或可分性，再把复杂度从暴力降到对数或线性。
5.3 从滑动窗口到更多 LeetCode 题型的联想
如果你刷题有总结的习惯，会发现 LeetCode 1052 这种题属于“一法通，百法通”的典型。它的解题套路可以无缝迁移到很多经典题目上：
- LeetCode 643：子数组最大平均数 I，固定窗口滑动的入门题。
- LeetCode 1004：最大连续 1 的个数 III，窗口长度可变，但同样用到“把 0 翻转成 1”的计数思想。
- LeetCode 209：长度最小的子数组，双指针收缩窗口，目标变成找最短窗口和。
再往外延伸，LeetCode 周赛 430 里这类滑窗题也经常出现，它们往往会把窗口条件包裹在一个新故事里，比如“连续 K 天的最优营业额”之类的场景，本质上还是这套东西。至于 LeetCode 旅行商这类题，已经是状态压缩 DP 的范畴，和滑窗差距较大，但那种题对“状态定义”的讲究，和本题对“窗口统计量”的讲究，底层思维是相通的。
我自己刷题时有个习惯：每做完一道滑窗题，就在题解笔记里顺手把同类型的题号列进去，后面复习时直接按家族刷，效率高很多。这道题我把它放在了“定长滑动窗口”分类下，和它挨着的是 643、1343、1456 这几道题。
6. 写在最后：这道题给我的实际体会
我标记的“耗时100”，有一部分时间其实不是花在写代码上，而是花在“确认窗口里到底应该累加什么”这件事上。很多题解一句话就带过了：“用滑动窗口维护生气顾客的和。”但如果你没有亲手推导过 base 和 extra 的拆分，这句话是飘的，你不知道为什么窗口里只统计生气顾客，也不知道 base 和 extra 为什么不会重叠。
我自己后来想通的方式，是把问题换成一个生活化的类比：假设你是一家奶茶店的店长，某个店员平时服务态度不好，导致一批顾客给差评。现在你决定让这个店员在连续 X 分钟内保持微笑，那你当然应该挑“他原本态度最差、客流又最大”的那段时间去让他微笑，这样才能挽回最多的差评。固定时长、挑选最优连续时段，这不就是滑动窗口吗？
如果你现在正在刷 LeetCode 热门 100 题，我建议你把这道题和“前缀和”“差分数组”“双指针”放在一起对比着看。不要只满足于 Accepted，试着用暴力解、滑窗、前缀和三种写法各交一次，体会一下它们在时间和空间上的差别。等你把这道题完全吃透，再遇到类似“固定长度窗口最优化”的题，基本就能一眼看穿了。
最后再分享一个小技巧：刷题时遇到这种带故事情节的题目，第一步永远是翻译题面。把“老板生气”翻译成 grumpy[i] == 1，把“顾客不满意”翻译成“不计入满意值”，把“克制 X 分钟”翻译成“选择长度为 X 的子数组”，一道 Medium 题瞬间就成了模板题。别让故事干扰你，这才是刷题速度提升的关键。