每日温度与单调栈：透彻理解“下一个更大元素”问题

前阵子在 LeetCode 刷力扣热题 100，进度走到第 72 题的时候停了一下：每日温度，标签写着“栈”。这题光看描述非常友好，就是给你一个每天温度的数组，让你返回另一个数组，记录“再过几天会出现比今天更高的温度”，如果后面没有更高温度就填 0。但真正上手写会有一个尴尬的情况：暴力解法几行就写完，提交也能过，可你总觉得没抓到点子上。

直到我把单调栈想清楚，才明白这题为什么能在热题 100 里占一个位。它其实是一个非常标准的“右侧第一个更大元素距离”问题，也是后面接雨水、柱状图最大矩形、下一个更大元素那一串题的地基。想认真把栈这一块吃透的人，这道题绕不过去。写下这篇，是把自己推演时的思路、踩过的边界和调试方法整理一遍，顺便给后面刷题的人一个可以直接照抄的版本。

下面按我实际做题的顺序来聊：先看题面到底在问什么，再讲为什么单调栈合适，最后给两个能 AC 的写法，以及容易翻车的细节。

1. 先别急着写代码：把每日温度的“为什么”拆透

1.1 题目要求的是“右侧最近更高温度的距离”

先把题面翻译成大白话：数组 temperatures 的长度为 n，结果数组 answer 的长度也是 n。对于下标 i，要找的是 j > i 且 temperatures[j] > temperatures[i] 的最小的 j，然后让 answer[i] = j - i。如果不存在这样的 j，就写 0。

这里有两个容易被忽略的点。

第一个点是“大于”而不是“大于等于”。假如第 1 天是 73 度，第 2 天也是 73 度，那第 2 天并不能算作第 1 天“更高温度”的答案。很多刚开始写的人会在 > 和 >= 上翻车，后面第 5 节我会专门展开。

第二个点是答案填的是“几天后”，本质是下标差。比如 i=0 那天对应 73，j=2 那天对应 76，相差 2，所以答案是 2 而不是“从第 0 天开始数，过 3 天到第 2 天”这种数法。下标差 j - i 是唯一标准，少算一天多算一天都会导致例子都过不了。

所以整个问题浓缩成一句：对每个元素，找到它右边第一个比自己大的元素的下标，然后算距离。找不到就给 0。这就是“下一个更大元素（Next Greater Element）”的变形。

1.2 暴力解法的问题到底出在哪

没接触过单调栈的人，第一反应一定是两层循环：

python复制def dailyTemperatures(temperatures):
    n = len(temperatures)
    ans = [0] * n
    for i in range(n):
        for j in range(i + 1, n):
            if temperatures[j] > temperatures[i]:
                ans[i] = j - i
                break
    return ans

这段代码逻辑完全正确，小数据下也没什么问题。但它的复杂度是 O(n²)。最坏情况是什么？比如温度严格递减：[30, 29, 28, 27, ...]，每个元素后面都没有更高温度，内层循环却要把后面的元素全都扫一遍才知道不存在。总比较次数接近 n + (n-1) + (n-2) + ... + 1，也就是大约 n² / 2。

只要 n 到几千，比如 5000，内层操作就是一千多万次，还没什么感觉。但如果 n 到十万甚至更大，O(n²) 就会非常吃力。LeetCode 上这题的常规数据量并不算极端，可热题 100 的目的从来不是“能跑就算过”，而是让你从暴力解里提炼出可以复用的思路。所以这道题的正确姿势是学会用什么信息把“已经看过的、还没找到答案的天”组织起来，让每个元素只处理常数次。这个数据结构就是单调栈。

1.3 为什么“栈”会出现在这里

很多人学栈的时候只记住“后进先出”，真到做题时又不知道什么时候该用。每日温度这个场景里有一个非常重要的时间特征：我们是从左往右，也就是从早到晚处理每一天的。当某一天温度升高时，它影响的不是“未来”，而是“过去”。

比如你扫描到第 100 天，温度突然很高，那么第 90 天、第 85 天、第 70 天这些还在等待答案的日子，可能都在等这个“第 100 天”作为它们的下一个更高温度。这种“后来的高温天，一次性回答前面若干天的问题”的操作，天然就是一个撤销式结构：前面那些天入栈保存，遇到满足条件的日子再按一定顺序出栈结算。栈的后进先出，恰好能保证每次弹出的都是“当前还没结算的日子里离现在最近的那个”，也就是最应该先被回答的那个。

这里并不是说所有“向后看”的题都用栈，而是说当你有大量“悬而未决”的候选，并且新来的元素可以一次性解决多个候选时，用栈来维护候选集合会非常合适。想明白这一步，后续代码就不难理解了。

2. 栈还能这么玩：单调栈的核心不变量

2.1 用“排队结算”来理解单调栈

单调栈不是新的 API，它就是我们熟悉的栈，只不过在入栈前多做了一步：不断弹出栈顶，直到栈顶元素满足某个单调条件，然后把当前元素压进去。这样，栈内元素从栈底到栈顶会保持递增或递减。

放在每日温度里，从左往右扫描时，我希望栈里装的都是“正在等待更高温度的日期”。这些日期的温度应该是从栈底到栈顶逐渐下降的。为什么？

我举个例子。假设栈底温度 75，栈顶温度 70，中间还有一些比 70 高的温度。此时我扫描到一个新温度 71。71 先和栈顶 70 比较，70 比 71 小，所以 70 找到了它的答案，出栈。再往下看，如果下一个栈顶是 74，74 大于 71，说明 71 这个温度对 74 那天来说还不够高，74 还得继续等。于是 71 入栈，成为新的栈顶。

栈里从底到顶的温度大致保持从高到低，同时下面的日期一定比上面的日期更早。原因很简单：新扫描到的日期总是更晚，它会压在栈顶；如果它的温度比栈顶更低，它不会影响之前的等待者，只是自己成为一个新的“等待者”。如果它的温度比栈顶更高，那它会先解决栈顶那个日期，然后再看更早的日期，直到栈空或者栈顶温度不再小于自己为止。

换一种说法：栈里保存的不是所有天，而是一个“越来越难被满足”的候选序列。越靠近栈顶的日期温度越低，因此越容易被未来某天“拯救”；离栈顶远的日期温度高，必须等一个更高的温度才能被拯救。

2.2 为什么“保持递减”就不会漏答案

很多人第一次看到“维护单调”会觉得这是在搞技巧，其实它背后有一个很强的保证：任何被弹出栈的日期，都已经找到了它需要的答案。弹出之后，它就不会再被未来某天扫描到，因此不会导致误判。

为什么能保证找到答案？因为当前扫描到的温度 temperatures[i] 如果大于栈顶温度 temperatures[stack[-1]]，那么对于栈顶那一天来说，i 就是在它右侧第一个比它大的温度。为什么能肯定是“第一个”？因为从左往右扫描时，所有更早的日子都已经处理过；如果 i 之前存在某一天能让栈顶那天升温，那栈顶那天早就会被弹出了，根本不会留到现在。既然它能等到 i，说明 i 就是第一个能回答它的日子。

如果 temperatures[i] 不大于栈顶温度，那就继续让栈顶等待，把当前天入栈。由于当前天温度更小，它不会影响栈顶已有的相对高温日期，也不会破坏“从底到顶温度递减”的结构。

这里的核心不变量是一句话：栈中元素的温度，从栈底到栈顶单调递减，且栈中元素的下标从左到右单调递增。每次操作要么弹出并结算，要么压入新下标，栈的性质始终成立。因为这个性质，我们可以用均值摊还的思路证明总时间复杂度是 O(n)。每个下标最多入栈一次、出栈一次，所以哪怕 while 循环看起来可能连续弹出很多元素，整体弹出次数也超不过 n 次。

2.3 左右两个方向，本质是同一件事

用单调栈处理每日温度，其实有两条路。

第一条路是从左往右扫描。此时栈里保存的是“右侧答案还没确定的日期”，新元素负责去结算栈顶。这是大多数人比较顺手的正向思维：“我先保存过去，等未来来了再回答过去”。

第二条路是从右往左扫描。此时栈里保存的是“当前已经扫描过的右侧候选日期”，用来给当前位置找答案。每到一个新位置，先看看右侧有没有比它高的温度候选。如果有，栈顶就是距离最近的；如果没有，答案就是 0，然后把当前位置也作为候选加入栈中。

很多题解默认写的都是从左往右的版本，但从右往左其实也很好理解，而且它更接近“找右边第一个比自己大的元素”的自然语义。两条路选一条自己喜欢的就行，关键是要把“栈内存什么、何时出栈、何时结算”这三件事想清楚。

3. 手写两种能 AC 的代码

3.1 从左往右：碰到更高温度就结算

这是我自己最常用的一版，代码很紧凑：

python复制def dailyTemperatures(temperatures):
    n = len(temperatures)
    ans = [0] * n
    stack = []

    for i in range(n):
        while stack and temperatures[i] > temperatures[stack[-1]]:
            prev = stack.pop()
            ans[prev] = i - prev
        stack.append(i)

    return ans

逻辑拆开是这样的：i 是当前扫描到的日期。只要栈不为空，并且当前温度比栈顶那一天的温度高，就说明栈顶那天等到了它的答案。prev 就是栈顶那天的下标，i - prev 是经过的天数，填入 ans[prev]，然后弹出。如此反复，直到栈空，或者当前温度不再比栈顶温度高。最后把当前下标压入栈中，表示“这一天还没找到答案，继续等待”。

为什么这里比较用的是 temperatures[i] > temperatures[stack[-1]] 而不是 >=？因为题目要求“严格更高”。如果温度相等，它不能作为栈顶那天的答案，应该让栈顶继续等待。注意这里有一个很有意思的细节：两个相等的温度如果都入了栈，当某个更高温度出现时，靠后的那个相等温度会先被弹出，靠前的会晚一步被弹出，但它们的下标差分别是 1 和 2，结果依然是正确的。所以从左往右时，相等温度不会被错误地提前结算。

栈中下标对应的温度天然保持递减。如果相同温度出现多次，栈里会出现连续相等的温度，它们会顺序等待，遇到新高温时从右往左逐个被弹出，不会被漏掉。

3.2 从右往左：维护右侧候选日期

第二种写法是反向扫描：

python复制def dailyTemperatures(temperatures):
    n = len(temperatures)
    ans = [0] * n
    stack = []

    for i in range(n - 1, -1, -1):
        while stack and temperatures[i] >= temperatures[stack[-1]]:
            stack.pop()

        if stack:
            ans[i] = stack[-1] - i

        stack.append(i)

    return ans

从右往左时，stack 里存放的是“在当前日期右侧的温度候选”。每次处理新日期 i，我们先看栈顶。如果栈顶温度不高于当前温度，说明这个候选不可能是当前日期“严格更高温度”的答案，同时它对更左边的日期也没有价值：因为当前日期更靠左，温度还更高，未来如果有比当前更高的温度，它肯定比这个栈顶候选更强；栈顶候选可以被安全丢弃。所以用一个 >= 把等于或低于当前温度的候选都弹出。

弹出后如果栈还有元素，栈顶就是右侧第一个严格更高的温度吗？是的。因为栈里剩下的候选都是严格高于当前温度的，而它们按下标从近到远排列，栈顶就是离当前日期最近的那个。于是记录 stack[-1] - i。最后把当前下标压入栈，作为更左侧日期的候选。

这里有一个特别容易写错的地方：从右往左时，while 条件里必须用 >=，不能只写 >。如果只写 >，遇到连续相同温度时，偏右的相同温度会留在栈里，导致左侧相等温度误以为“右边一天后就有更高温度”，从而算出错误答案。比如温度是 [73, 73, 74]，下标 0 的 73 右边第一个更高温度应该是下标 2 的 74；如果从右往左扫描时没有把下标 1 的 73 弹出，下标 0 会错误地得到 1 天。这个细节我在第 5 节还会再强调。

3.3 两版代码应该怎么记

很多初学者会在两种写法之间反复横跳，最后哪个都记不牢。我的建议是：先记住从左往右的版本。它只有一个 while，判断条件就用“当前温度大于栈顶温度”，然后把弹出的下标和当前下标做差；最后无论有没有发生结算，都要把当前下标入栈。这个模板可以扩展到很多“下一个更大元素”的题目。

从右往左的版本可以作为对照。它更适合当你已经知道右侧全部信息、需要给每个位置找“右侧最近更大”的题目。两个版本的时间复杂度和空间复杂度完全一样，选一个用熟，另一个能看懂即可。手写代码的时候最怕两个版本记混，比如从左往右的 while 里写成了 >=，或者从右往左的 while 里忘了 >=，都会在相等温度上出问题。

4. 完整跑一遍样例，顺便验证边界

4.1 手推一次栈的变化过程

拿题目自带的例子来推一遍最好，输入为：

text复制temperatures = [73, 74, 75, 71, 69, 72, 76, 73]

这里栈中保存的是下标，为了直观，我在表里写“下标(温度)”。

最终 ans = [1, 1, 4, 2, 1, 1, 0, 0]，和第 3 天也就是下标 2 的 75 需要等 4 天才等到 76 完全吻合。特别注意下标 3 的 71，它右边第一个比它高的温度是下标 5 的 72，中间隔着下标 4 的 69，所以答案是 2 而不是 1。这个案例能把“不是每个元素都等最近的下一个元素，而是等最近的下一个更高值”这个点说清楚。

手推过一次之后，你会发现整个过程中没有任何一个元素被重复比较很多次。虽然第 6 轮一次性弹出了两个元素，第 7 轮也弹出了两个元素，但每个元素都只弹出一次，所以总操作量是线性的。

4.2 几种容易出错的输入速查

光看示例还不够，刷题时真正让你怀疑人生的往往是边界用例。这里有几种我觉得值得保存的输入：

特别是 [73, 73, 74] 这一条，我建议你一定要自己手推一遍。从左往右的写法中，遇到第二个 73 时不会弹出第一个 73，而是会把它压在栈里；等 74 出现时，先弹出第二个 73，填 1，再弹出第一个 73，填 2。顺序上先弹出的反而是更靠后的相同温度，这也非常符合栈的后进先出特性。

4.3 空间复杂度与极端情形

栈的最大深度会是多少？最坏情况是温度单调递减，所有元素都会入栈且等不到结算。例如输入 [100, 99, 98, ..., 1]，栈里最多会同时存在 n 个下标，空间复杂度 O(n)。结果数组本身也要 O(n)，所以总空间复杂度是 O(n)。

时间复杂度上，尽管 while 循环看起来可能在一个 for 循环里连续弹掉很多元素，但你要意识到，弹掉的元素再也不会回来。每一次入栈最终要么被弹出，要么留到程序结束。入栈最多 n 次，弹出最多 n 次，所以总共的 while 执行次数不超过 n。这个摊还分析的思路在做很多单调栈题时都成立，学会之后看代码会通透很多。

5. 常见翻车点与调试技巧

5.1 相等温度是最容易翻车的点

我见过很多次，也包括我自己第一次写：从左往右扫描时，while 条件写成了 temperatures[i] >= temperatures[stack[-1]]。这在 [73, 74, 75, ...] 这种输入上不会出问题，因为不存在连续相等温度。但只要一碰到 [73, 73, 74]，错误就立刻暴露：第二个 73 入栈前会把第一个 73 弹出，并错误地认为第一个 73 的答案就是 1 天。如果当时没注意隐藏用例，就会莫名 WA。

反过来的问题同样存在：从右往左扫描时，while 条件只写 >，忘了 >=。这样遇到相等温度时，右侧的相等温度不会被丢弃，它会让更左侧的相等温度误以为“右边一天后就有更高温度”，结果输出 [1,1,0] 而不是 [2,1,0]。

所以我的建议是：选定一种方向之后，把“严格更高”四个字刻在脑子里。从左往右时，触发结算的条件是当前温度严格大于栈顶温度；从右往左时，丢弃候选的条件是当前温度不低于栈顶温度。两者方向相反，不要想着死记硬背，而是手动推一遍相等温度的例子，理解了就忘不掉了。

5.2 栈里到底存下标还是存值

最开始我写过一版栈里直接存温度值，然后答案死活算不出来，因为光有值无法知道“到底是哪一天”。每日温度要求输出天数差，所以必须能拿到下标。正确做法是栈里存下标，需要比较温度时再通过下标去原数组取值。

如果你实在喜欢存 (下标, 温度) 这种元组，也不是不行，但会多一层解包，代码反而臃肿。在单调栈模板里，习惯是“栈内存下标，值通过下标访问”。这样后续遇到需要算长度、算面积、算距离的题时，都能直接复用。比如接雨水、柱状图最大矩形这些题，栈里存下标几乎是通用的。

5.3 空栈短路问题

Python 里写 while stack and temperatures[i] > temperatures[stack[-1]] 时，很多人会先写温度比较，再补 stack，结果写成 while temperatures[i] > temperatures[stack[-1]] and stack。如果栈是空的，stack[-1] 会直接抛 IndexError，而 and 后面的 stack 根本不会执行。

同样的坑也出现在从右往左版本里。任何时候只要你要访问 stack[-1]，就必须保证前面已经判断过 stack 非空。Python 的短路求值顺序是 and 从左到右执行，所以一定要把 stack 放在温度比较前面。这个是熟练工也会偶尔犯的低级错误，但测试用例一多就会暴露。

5.4 调试时给栈加上“观察日志”

如果某个用例答案不对，最快的调试方法是在关键位置打印栈的变化。下面是一段带观察日志的脚本思路，可以直接跑来看看：

python复制temperatures = [73, 74, 75, 71, 69, 72, 76, 73]
n = len(temperatures)
ans = [0] * n
stack = []

for i in range(n):
    print("处理 i =", i, "温度 =", temperatures[i], "入栈前 stack =", stack)
    while stack and temperatures[i] > temperatures[stack[-1]]:
        prev = stack.pop()
        ans[prev] = i - prev
        print("  弹出", prev, "答案", ans[prev])
    stack.append(i)
    print("  入栈后 stack =", stack)

print(ans)

实际运行时，你可以看到下标 3 的 71 会在下标 5 的 72 到来时被弹出，而不是在下标 4 的 69 到来时被弹出，因为这个 69 并不比它高。盯着日志推几遍，你对“谁在使用栈顶元素”“谁在出栈”的理解会快很多。

调试还有一个判断方法：如果你发现某个输入下 ans 大部分都是 1，而正确答案不是，多半就是相等温度被错误弹出了。如果发现某些天本该有答案却输出 0，那多半是 while 条件用成了 >=，导致它被过早地留在栈里再也没等到结算。

5.5 从 Time Limit Exceeded 反推代码问题

还有一类问题是“小数据能过，大数据超时”。这种情况几乎可以肯定是代码不小心退化成了 O(n²)。一种常见原因是出栈后没有及时更新答案，导致每个元素反复贡献比较。另一种可能是在栈中保存值而不保存下标，然后为了找答案又去原数组里遍历查找，引入了额外复杂度。

遇到超时不要慌，先想想：这个元素到底会被弹出几次？如果某个下标可能被重复访问多次，那就说明你的做法不是严格的线性。每日温度正确写法的魅力就在于每个下标只入栈一次、出栈一次，没有任何下标会被重复处理。

6. 从每日温度延伸出去：它不只是“一道栈题”

6.1 它属于“下一个更大元素”家族

每日温度解决的是“右侧第一个更大元素的距离”。这类题在算法里是一个大家族。LeetCode 上很出名的还有 496 下一个更大元素 I、503 下一个更大元素 II、84 柱状图中最大的矩形、42 接雨水，全部都能看到单调栈身影。

它们的通用套路是：从左到右遍历数组，用栈维护一组“当前尚未找到答案的候选”；当新元素能“压过”栈顶时，就说明栈顶等到了结果，此时弹出栈顶并完成结算。区别只在于栈顶存放的信息、结算时计算的是距离、面积还是贡献值。如果你能把每日温度的弹出逻辑吃透，后续做接雨水时会自然想到“每个柱子左侧第一个更矮、右侧第一个更矮”等结构。

初学者容易犯的一个误区是一题一题地背代码。我更建议把“下一个更大元素”作为一条主线，做一道题就总结一次，然后回头看每日温度，会发现它只是这套模板里最简单的版本。

6.2 如果温度数组是环形的怎么办

503 题问的就是环形数组里的下一个更大元素。如果题目改成：温度数组首尾相接，每天的下一个更高温度可能绕到数组开头，怎么处理？

套路是把数组逻辑上复制一份，让长度变成 2 * n，然后用从右往左的扫描处理。为了保证下标不越界，常见的写法是在循环里让 i 从 2 * n - 1 遍历到 0，真正的下标是 i % n。这样每个位置在第二轮扫描时，会看到第一轮中在它后面的所有元素，等价于绕了一圈。

本质上，环形数组不会改变单调栈的维护逻辑，只会让每个元素最多被扫描两次。比如温度是 [73, 74, 73]，对于最后一个 73，右边的更大温度是绕回数组开头的 74，距离为 1。环形数组的题目也很适合用来检验自己是不是真的理解了单调栈，因为只把数组翻倍然后套模板是很容易出错的。真正的关键是想清楚“哪个环回的距离才不会被重复计算”。

6.3 结合题目背景：真正的气象数据处理思路

从实际工程角度想一下，每日温度这种“预测未来几天是否升温”的需求，在气象数据、温控系统里并不少见。真实数据里如果只有几千个点，暴力完全够用；但如果要对每秒级别的传感数据做实时处理，就需要流式地维护一个单调栈：

• 每来一个新温度，先把栈内所有比它旧且温度更低的记录弹出，因为它们的答案就是当前新温度；
• 弹出的记录生成“该时刻到当前时刻的升温间隔”；
• 把当前时刻入栈，等待下一次升温。

这种方案可以做到每个数据点只处理常数次，内存只保留当前还没有升温的候选。所以不要觉得算法题只在面试里有用，单调栈在需要“寻找事件后的下一个阈值”的场景里，是一个相当实用的在线处理工具。不过工程实现时还要考虑数据采集时间戳、异常值剔除、窗口过期等问题，这就比 LeetCode 题面复杂多了。

最后再分享一点做题的节奏

如果你刚开始刷栈的题，我的建议是别急着看题解，先自己从暴力开始推。把 [73,73,74] 这种反例手算一遍，再去看单调栈，就会发现相等温度这个坑其实不是“细节”，而是题目定义的核心。我自己在二刷这道题时，发现从右往左的版本更好理解，因为它和最直观的“向右看”完全一致。后来做接雨水，反而更喜欢从左往右的结算版，因为它能自然地处理“左边和右边共同决定水量”的关系。

按照我个人经验，每日温度值得二刷。第一遍能 AC 不算什么，第二遍能不看代码写出两种方向，并且解释清楚为什么相等温度不能算更高，才算真正过关。之后再遇到 84、42 这些题，你会觉得它们和每日温度之间有一根线连着，而不是每次都要重新发明一遍数据结构。