LeetCode刷题51天复盘：面试经典150题的高频考点与解题模板

坚持刷 LeetCode 到第 51 天，正好是一个值得停下来复盘的时间点。我手头的题单是官方那套“面试经典 150”，早起先做一道，晚上有时间再补一道，偶尔状态不好就改成只做一道精读，但断更是不允许的。到今天为止，我已经把题单里最核心的几个知识点过了第一轮，期间踩过的坑、悟出来的套路、还有那些“本来以为会做、面试时却卡住”的题目，都值得好好写一写。

“面试经典 150”这个名字听起来像是一个刷题清单，但它其实是一套非常精准的面试命题地图。它不像“热门 100”那样追求题目的流量和话题度，而是按照面试官的真实出题习惯，把数据结构、算法、DP、图论、贪心、滑动窗口等高频考点拆成一个个可控的知识块。对于正在准备技术面试、尤其是大厂技术面的朋友来说，这套题单比盲目刷几百道随机题要高效得多。我这 51 天最深的感受就是：刷题这件事，数量不是重点，覆盖面才是。

这篇文章不打算再讲“如何注册 LeetCode”“怎么提交代码”这种基础操作，而是想把这 51 天的阶段性复盘内容完整记录下来，包括我对这个题单的理解、几类高频考点的通用解法、以及几道经典题目的完整思考过程。无论你是刚开始准备面试，还是刷题刷到中途想调整方向，都应该能从里面找到一点参考价值。

1. 题单选择背后的逻辑：为什么是“面试经典 150”而不是别的

1.1 它跟“热门 100”“剑指 Offer”到底有什么区别

很多人在刷题初期都会遇到一个选择题：到底从哪个题单开始刷？市面上最常被提到的三套题单，分别是 LeetCode 自带的“热门 100”“面试经典 150”和《剑指 Offer》系列。三套题单我都用过，它们的风格差异其实非常大。

热门 100 的特点是“流量导向”，收录的是社区里被讨论最多、点赞最多、热度最高的题目。这套题单的好处是每道题都不会太偏，坏处是它没有按照面试维度做归类，刷起来容易东一榔头西一棒子，今天做一道滑动窗口，明天跳到一个冷门位运算，知识的连贯性比较差。

剑指 Offer 的思路是“面试场景导向”，题目难度整体偏低，很多题目在真实面试里确实会出现，但它的体系比较在意“基础”和“熟练”，对于已经具备一定代码能力的候选人来说，覆盖度会显得不够。

面试经典 150 的设计更偏向“知识结构导向”。它把题目按照数组、字符串、哈希表、双指针、滑动窗口、矩阵、栈、链表、树、图、回溯、贪心、DP 等分类整理，每一类下面有若干道最典型的题目。这套结构最大的价值是：刷完一遍之后，你能在脑子里建立起一个“题目类型地图”，面试时看到题，能快速把它映射到某个知识点上，进而想到对应的解题模板。这个“快速映射”的能力，恰恰是面试中最值钱的能力。

1.2 51 天里我对这套题单节奏的调整

刚开始刷的时候，我给自己定的目标是每天 3 道新题，坚持了大约一个星期就崩了。倒不是时间不够，而是到了第 8 天左右，我发现前面刷过的题目已经开始遗忘，复现的时候连思路都理不清，更别提手写代码了。

后来我把节奏改成“1 新 + 1 旧”，也就是每天做一道新题，再复现一道旧题。复现旧题的时候要求自己不看之前提交的代码，从零开始，在编辑器里把完整代码打出来，能跑通再算过。这个办法极大改善了遗忘问题，代价是进度慢了，但知识留存率高了很多。

另一个重要的调整是“分组刷题”。我不再按题单顺序逐题刷，而是先把题单扫了一遍，把题目按自己的熟练度分成了三组：已经会的、看上去眼熟但写不出来的、完全没思路的。优先级放在第二组，因为第三组往往需要大量前置知识，强行硬啃效率很低，而第一组只需要隔几天做一次保持手感就行。

这 51 天刷下来，我大概完成了题单里 80 道左右的核心题目，其中约 45 道是以前没做过的。这个速度不算快，但我能明显感觉到，现在拿到一道陌生题目时，脑子里浮出的不再是一片空白，而是几个候选知识点的拼图。我觉得这才算真正摸到了刷题的门道。

2. 阶段性复盘：5 个高频考点的通用打法

2.1 字符串与回文：从中心扩展到 Manacher

字符串是面试里最容易被出题人“加戏”的考点，而回文问题又是字符串里的“顶流”。LeetCode 第 5 题“最长回文子串”就是一个典型的例子，我刷到这道题的时候，发现它几乎把字符串题的几种思路都给串起来了。

最直观的思路是暴力枚举所有子串，再逐个判断是否为回文，时间复杂度 O(n³)，在 LeetCode 上直接超时。稍微优化一下，把“判断回文”和“枚举起点终点”合并，就得到了中心扩展法：每次选定一个中心点（可能是一个字符，也可能是两个字符之间的空隙），向两侧扩展，统计能够形成的最长回文长度。这个做法的时间复杂度是 O(n²)，空间复杂度 O(1)，几乎所有人都能做到这个程度。

再往上走，就是 O(n) 的 Manacher 算法。这个算法的核心思路是通过一个现有的回文半径数组来避免重复比较，把已经被验证过的回文区间记录下来，后续中心扩展时可以直接跳过已经确定不会更长的部分。我用一个实际例子解释一下：字符串“abaxabay”，如果已经知道以位置 3 为中心的回文半径是 3，那么当中心移动到位置 6 时，就可以直接参考位置 3 的对称信息，而不需要重新从两边扩展。

Manacher 在面试中的出场频率不像中心扩展那么高，但如果你能把它讲清楚，面试官对你的印象分会明显提高。我个人刷题时的策略是：中心扩展必须能闭着眼睛写出来，Manacher 至少要能说明白原理，并且能在提示下实现。如果你一个字符串算法都没时间准备，那请优先把中心扩展吃透，它已经能覆盖绝大多数面试情境了。

2.2 二分查找：边界条件才是真正的分水岭

二分查找在“面试经典 150”里的存在感非常高，但它不是简单考“有序数组找目标值”这种模板题，而是会把二分的变体玩出花来。LeetCode 875“爱吃香蕉的狒狒”就是一道非常经典的“二分答案”题。

这道题的情境是：狒狒要在 h 小时内吃完 n 堆香蕉，每堆香蕉数量是 piles[i]，它每小时只能选择一堆来吃，并且一小时最多吃 k 根，如果这一堆不足 k 根，那它吃完这堆之后这一小时剩余的时间就得闲着。问题是求最小的 k 值，使得狒狒能够在 h 小时内吃完所有香蕉。

很多第一次做这道题的人会按“模拟吃香蕉”的思路去推，结果发现随着 k 的变化，吃香蕉的总时间会随之变化，但这种变化不是线性的，逐一遍历肯定超时。正确的做法是把“速度 k”当作自变量，把“吃完所有香蕉所需的总时间”当作因变量，这两个变量之间是一个单调递减的关系：k 越大，耗时越少，k 越小，耗时越多。于是问题就变成了：在 [1, max(piles)] 这个区间里，二分查找满足“总耗时 <= h”的最小速度。

这道题我踩过一个很典型的坑：计算单堆耗时的时候，我一开始直接用 piles[i] / k 向下取整，结果每堆剩下的一部分香蕉没有算进去。正确做法应该是 (piles[i] + k - 1) / k 向上取整，这样才能保证不到 k 根也被算作一小时。

边界条件在二分题里永远是重灾区。拿这道题来说，左边界是 1（速度至少要每小时 1 根），右边界是 max(piles)（速度超过最大堆的数量也不会再节省时间，因为每小时最多只能吃一堆）。这两个边界选错任何一个，答案都会跑偏。我建议做二分题时统一采用“左闭右开”或者“左右都闭”的写法并固定下来，不要每道题换一种，否则出错率会直线上升。

2.3 DFS、回溯与 DP：它们其实是同一棵决策树

LeetCode 494“目标和”是一道特别适合用来打通 DFS、回溯和动态规划三者关系的题目。题目长这样：给你一个整数数组 nums 和一个目标值 target，你可以给每个数字前面添加“+”或“-”，求有多少种不同的方案，使得最终运算结果等于 target。

我最早做这道题时，第一反应就是 DFS。每个数字有两种选择，加或者减，那就相当于在一棵二叉树上做遍历，走到叶子节点时判断和是否等于 target，等于则计数加一。这种做法的复杂度是 O(2^n)，当 n 很大时直接爆炸。但它在思路上是完全正确的，只是少了剪枝和记忆化。

接下来我想到的是加一个 memo：用 (index, current_sum) 作为状态记录下来，如果同一个状态已经计算过了，直接返回之前的计数。这就是记忆化搜索，本质上是把一棵重复计算严重的递归树压缩成一个有向无环图。

还有一种思路是从另一个角度看问题：把加正的数总和记为 P，加负的数绝对值总和记为 N，那么 P + N = sum(nums)，P - N = target，于是 P = (sum + target) / 2。问题就转化成了“从数组里选出若干个数，使它们的和为 P”的方案数，这就变成了一个 0-1 背包问题，用一维 DP 数组就能做。

我觉得这道题是“同一棵决策树”三种打开方式的最佳示例，因为 DFS 是树的自顶向下遍历，记忆化搜索是树的剪枝，DP 是把树的复用关系反向建模。面试时如果能把这三者之间的关系讲明白，比背十个模板都管用。

2.4 滑动窗口与双指针：把暴力尝试压缩成线性的艺术

刷到第 30 天左右，我明显感觉到一道分水岭：很多题目暴力做是能做的，关键是能不能优化到线性复杂度。滑动窗口和双指针，就是这类线性优化里最常用的两个套路。

滑动窗口的核心思路其实很简单：与其每次重新从开头遍历到结尾，不如让窗口的右边界不断右移，同时根据条件决定左边界是否也要右移，窗口内部维护一个“当前区间”的状态。这样每个元素最多被加入窗口一次、移出窗口一次，整体复杂度就是 O(n)。

我自己的经验是，滑动窗口题最重要的是想清楚三件事：窗口的含义是什么、什么时候收缩窗口、收缩窗口时是否需要更新答案。这三件事如果有任意一件没有定义清楚，写出来的代码大概率会在边界上出错。

双指针和滑动窗口经常一起出现，但双指针更强调“两个指针各自负责一个维度”。最典型的例子是“有序数组的两数之和”，一个指针放在开头，一个指针放在末尾，根据当前和与 target 的关系决定移动哪个指针。这个“相向双指针”的思路简单到看一眼就会，但它背后的数学直觉——利用有序性排除不可能的方向——值得反复咀嚼。

2.5 链表与树的递归：画图比写代码重要十倍

刷链表题的时候，我强烈建议准备一个草稿本，每道题先把图画出来，再动手写代码。链表题的所有难点集中在“指针的先后顺序”上，比如反转链表，你需要先把 next 节点存下来，再改当前节点的 next，再移动 prev 和 current。如果你的代码里这三步顺序乱了，轻则死循环，重则直接丢节点。

树的问题就更依赖递归了。树本身就是一个天然递归结构，几乎所有树的算法都能用递归解决，核心是“假设子树已经处理好了，我只需要管当前节点”。我刷树相关题目时有个心法：先把递归的边界条件写出来，再处理中间逻辑，最后检查返回值是否在每一层分支里都覆盖到了。

3. 实操实录：三道经典题目的完整复盘

3.1 最长回文子串：从暴力到 O(n) 的渐进优化

LeetCode 第 5 题“最长回文子串”，是我在做“面试经典 150”字符串分类时刷到的一道题。这道题很适合作为热身题，但我发现很多人在面试现场只能写出 O(n²) 的解法，一旦被追问“能不能做到 O(n)”就卡住。

先说我最终采用的代码方案。中心扩展法，我用 Python 实现是这样：

python复制def longestPalindrome(s: str) -> str:
    if not s or len(s) < 1:
        return ""
    
    start, end = 0, 0
    
    for i in range(len(s)):
        len1 = expand_around_center(s, i, i)      # 奇数长度回文
        len2 = expand_around_center(s, i, i + 1)  # 偶数长度回文
        cur_len = max(len1, len2)
        if cur_len > end - start + 1:
            start = i - (cur_len - 1) // 2
            end = i + cur_len // 2
                
    return s[start:end+1]


def expand_around_center(s: str, left: int, right: int) -> int:
    while left >= 0 and right < len(s) and s[left] == s[right]:
        left -= 1
        right += 1
    return right - left - 1

这个代码里最容易被忽略的是奇数长度和偶数长度的回文中心不一样。字符本身只能作为奇数回文的中心，而两个字符之间的“空隙”是偶数回文的中心。我在第一次写的时候只考虑了奇数中心，导致像“abba”这种输入永远返回错误结果。后来把中心扩展写成两个调用，分别传 (i, i) 和 (i, i + 1) 才解决。

如果面试官进一步追问 O(n) 的 Manacher 算法，这里有一个简化的实现版本供参考，它把原字符串每个字符之间插入 #，这样所有的回文都统一成了奇数长度，处理起来会更方便：

python复制def longestPalindrome_manacher(s: str) -> str:
    t = '#'.join(f'^{s}$')
    n = len(t)
    p = [0] * n
    center, right = 0, 0
    
    for i in range(1, n - 1):
        if i < right:
            mirror = 2 * center - i
            p[i] = min(right - i, p[mirror])
        while t[i + p[i] + 1] == t[i - p[i] - 1]:
            p[i] += 1
        if i + p[i] > right:
            center, right = i, i + p[i]
    
    max_len = max(p)
    center_index = p.index(max_len)
    start = (center_index - max_len) // 2
    return s[start:start + max_len]

Manacher 的最关键点是那个 min(right - i, p[mirror])：如果当前中心在已知回文区间内，就可以利用对称性得到一个初始半径，之后再做中心扩展。这样能保证每个字符最多被扩展一次，整体复杂度因此降到 O(n)。我在面试场上不会优先写 Manacher，因为它代码量偏大、边界多，容易写错；但如果面试官明确要求“优化到 O(n)”，就得能拿出来。

3.2 爱吃香蕉的狒狒：二分答案的标准范式

LeetCode 875 是“二分答案”这类题里最具有代表性的一道。很多二分题直接对数组下标二分，这道题不同，它是对“速度”这个答案本身二分。

我的完整代码如下：

python复制def minEatingSpeed(piles: List[int], h: int) -> int:
    def can_finish(k: int) -> bool:
        hours = 0
        for pile in piles:
            hours += (pile + k - 1) // k
        return hours <= h
    
    left, right = 1, max(piles)
    
    while left < right:
        mid = (left + right) // 2
        if can_finish(mid):
            right = mid
        else:
            left = mid + 1
            
    return left

这里的核心是 can_finish(k) 判断函数，它把“给定速度 k，能否在 h 小时内吃完”转化为一个布尔问题。这个函数必须严格单调，也就是说，k 越大，总耗时越小，满足条件的可能性越高。有了这个单调性，二分就成立。

我复盘时发现，很多人第一次做这道题会卡在右边界的选择上。为什么右边界是 max(piles)，而不是 sum(piles) 或者别的？因为当速度大于等于最大的那一堆香蕉数量时，最多一小时只能吃掉一堆，速度再大也不会让总时间变得更短。换句话说，max(piles) 已经是一个“绝对够用”的速度，再往上没有意义。这个“绝对够用”的上界直觉，在二分答案题里非常关键。

还要注意一个细节：(pile + k - 1) // k 是向上取整，它对应的是“每堆香蕉需要的小时数”。我初版代码直接写 pile // k，提交后在第几个用例就出现了差 1 的错误。这种边界差 1 在 LeetCode 的提交中非常常见，建议在写代码时先手动模拟一个简单用例，比如 piles = [3], h = 2，这时答案应该是 3，因为速度 2 时会超时，只有速度 3 才能在两小时内吃完。

3.3 目标和：从超时递归到 0-1 背包

LeetCode 494“目标和”是那道让我真正理解“DFS 过度到 DP”的题。我依次实现了三个版本，每一个版本都是对上一个版本的优化。

第一个版本是朴素 DFS，代码简洁但指数级超时：

python复制def findTargetSumWays(nums: List[int], target: int) -> int:
    def dfs(i, cur):
        if i == len(nums):
            return 1 if cur == target else 0
        return dfs(i + 1, cur + nums[i]) + dfs(i + 1, cur - nums[i])
    
    return dfs(0, 0)

第二个版本是记忆化搜索，用一个哈希表缓存已经访问过的状态：

python复制from functools import lru_cache

def findTargetSumWays_memo(nums: List[int], target: int) -> int:
    @lru_cache(None)
    def dfs(i, cur):
        if i == len(nums):
            return 1 if cur == target else 0
        return dfs(i + 1, cur + nums[i]) + dfs(i + 1, cur - nums[i])
    
    return dfs(0, 0)

第二个版本实际上已经能通过大多数测试用例，因为状态的规模远小于 2^n。不过更进一步，可以通过数学变形转成 0-1 背包，用一维数组动态规划解决：

python复制def findTargetSumWays_dp(nums: List[int], target: int) -> int:
    total = sum(nums)
    if (total + target) % 2 == 1 or total < target:
        return 0
    
    positive_sum = (total + target) // 2
    
    dp = [0] * (positive_sum + 1)
    dp[0] = 1
    
    for num in nums:
        for j in range(positive_sum, num - 1, -1):
            dp[j] += dp[j - num]
            
    return dp[positive_sum]

这个版本的核心是推导 P = (total + target) / 2 的过程。首先，所有数字加正号的集合记为 P，加负号的绝对值集合记为 N，那么 P + N = total，P - N = target，两式相加得到 P = (total + target) / 2。这里有一个前置条件：total + target 必须是偶数，且 total >= target，否则直接返回 0。

第三个版本里，那个内层循环为什么从 positive_sum 倒着遍历到 num？因为这是 0-1 背包，每个物品只能选一次，倒序遍历才能保证 dp[j - num] 是上一次外层循环更新过的值，而不是本次循环已经被当前物品更新过的值。如果正序遍历，就变成了完全背包，每个物品可以被选无限次，结果就错了。

这道题带给我的收获不是解法本身，而是“同一个问题，用不同复杂度视角去看，难度完全不同”的体验。面试中如果时间充裕，能从 DFS 逐步优化到 DP，会是一个非常加分的展示过程。

4. 面试视角：刷题如何真正转化为面试里的代码能力

4.1 面试官在代码题中真正考察的四件事

很多刷题人有一个误区，以为面试官最看重的是“能不能 AC”。真正参加过面试的人都知道，AC 只是及格线，面试官更在意的是：你遇到问题时是怎么思考的，你的代码能不能让人读得懂，你在边界条件和复杂度分析上有没有系统性思考。

第一件事是沟通。面试时拿到题目，不要闷头就写，应该先把自己的理解讲一遍，确认输入输出的约束条件，然后说出你准备使用的算法思路。这个“先说再做”的习惯，在面试官眼里价值极高，因为它模拟了真实工作中讨论架构方案的场景。哪怕你的思路不是最优解，只要沟通顺畅，也远比沉默写完一个最优解要加分。

第二件事是代码风格。LeetCode 提交代码时，你只要关心正确性，变量名随手写个 a、b、tmp 也没人管你。但面试现场不一样，面试官会一行一行读你的代码，变量命名可读性差、逻辑分支嵌套太深，都会让面试官皱眉。我建议从刷题第一天就开始练习“面试级代码风格”：函数名要能表达用途，局部变量名要有意义，复杂的判断条件提取成一个有名字的变量。这种习惯一旦养成，面试时根本不需要刻意调整。

第三件事是复杂度分析。时间复杂度、空间复杂度，这两个数字必须能脱口而出。你不仅要知道答案，还要能解释为什么是这个量级，比如二分答案每次缩小一半搜索空间、滑动窗口每个元素最多进出各一次，等等。面试官常会追问“能不能再优化”，如果你连当前方案为什么是这个复杂度都讲不清楚，那优化就更无从谈起。

第四件事是边界与异常处理。数组为空怎么办、目标值比所有数加起来还大怎么办、中间结果会不会溢出。这些不仅在面试题里是雷区，在实际工程代码里更是如此。LeetCode 的用例帮你挡掉了大部分边界问题，但面试官会故意把一些小边界挖出来问，你要养成主动思考边界的习惯。

4.2 刷题节奏与复盘方法：宁可慢一点，也要真正消化

刷题第 51 天，我总结出了一套目前最适合我的节奏，不一定适合所有人，但可以参考：

• 每周保持 6 天练习，周日只做复盘和错题复现，不碰新题。
• 每天 1 道新题 + 1 道旧题复现，新题控制在 40 分钟内，超时直接看题解并记录原因。
• 每道题做完后，写两行注释：一行记录解题思路的“一句话总结”，一行记录这道题卡住的原因（是没想起来用哪种数据结构，还是边界没考虑清楚）。
• 每周末把自己本周写过的代码全部重新看一遍，重点看错题和“AC 了但感觉写得冗长”的题。

这个复盘法最大的好处是，它把“刷题”从“拼题量”变成了“拼消化”。同样是刷 80 道题，一个人把所有题都过了一遍但每道题只做一遍就扔，另一个人做了 80 道题但每道题至少复盘 3 次，后者的面试表现会明显更稳定。

我还会在每次复盘时问自己一个问题：如果我明天面试遇到这道题，我能不能完全不看代码、在白板上把思路和代码写出来？如果答案是否定的，这道题就会被我加入“高频复现清单”。这个清单我固定在每天早晨最清醒的时候过一遍，效果比晚上临睡前过要好很多。

4.3 常见问题与自救指南

上面这些问题的根源，大多数时候不是“算法不会”，而是“思路没有系统化”。我自己的切身体会是：每道题解答完，不要急着看下一题，先停下来把这道题抽象成一个“题型模板”。比如「满足某个条件的最大值/最小值」，优先考虑二分答案；「所有可能的结果」优先考虑回溯；「最值/方案数」优先考虑 DP。拥有了这些模板，面试时才能做到“遇题不慌”。

还有一个容易被忽略的点：练手速。LeetCode 网页端有自动补全、有友好的报错提示，但面试的白板或在线文档编辑器没有这些。我建议刷题时如果有条件，尝试在没有任何语法提示的情况下写代码，把代码当作文本一样打出来。我前几次模拟面试时，就是因为在在线编辑器里连 Collections 和 Arrays 的区别都要想半天，导致代码写得很卡。后来我每次复盘，都要求自己在纯文本编辑器里把完整代码重新手写一遍，练多了之后面试时就有肌肉记忆了。

4.4 从“刷题”到“解题思维”的最后一步

说一个很多刷题博主不会讲透的点：刷题和解题思维之间，隔着“归纳总结”这一步。你刷 50 道双指针题，如果不主动去总结，你可能只会觉得“这些题有点像”，但说不清它们共同的思考框架。而如果你在每道题之后都问自己一句“为什么它能用双指针”，你会慢慢发现规律：双指针能优化的场景，往往是暴力解法中存在大量无效比较的情况。两个指针通过某种单调性，排除了那些不可能产生最优解的区间，从而把 O(n²) 的尝试压缩成 O(n)。

类似的总结还可以延伸到二分答案、DP 状态定义等几乎所有高频考点。带着“我要从这题里提炼出什么”的心态去刷题，哪怕是简单题，也能刷出收获。这也是我推荐所有人都来刷一遍“面试经典 150”的原因——它把知识点分好了类，你只需要在这个分类框架下做题、归纳、再做题，知识脉络会变得非常清晰。

5. 刷题到第 51 天：效率、心态与工具的一些经验

5.1 时间管理：上班族如何挤出每天两小时的做题时间

我身边有不少想刷题的人，出发点都很好，但往往坚持不过半个月，最主要的原因是时间安排不合理。上班族白天有工作，晚上回到家能挤出一两个小时已经很不容易，如果这段时间没有固定下来，很容易被各种琐事打断。

我的做法是：把刷题时间固定在早晨。闹钟调早一个小时，起床后先不碰手机，直接打开电脑做一道旧题复现，再做一道新题。早晨的脑子最干净，没有一天工作的疲惫感，做题效率比其他任何时间段都高。到了晚上，如果还有精力和时间，就再做一点题单里相对简单的题目，或者整理一下白天的思路。

这种做法的另一个好处是，哪怕晚上完全被加班或者紧急事务吞掉，当天也已经完成了一部分刷题任务，心理负担会小很多。断更与否往往不是意志力问题，而是你没有给任务安排一个“雷打不动”的时间窗口。早晨这个窗口对我来说最有效，你可以根据自己的作息情况寻找属于自己的固定时间。

5.2 我常用的三件套工具

刷题这件事，光有 LeetCode 一个网站是不够的。我用得最频繁的工具一共有三样，各有各的用途。

第一个是本地编辑器，可以是 VS Code、JetBrains 全家桶或者任何你习惯的 IDE。LeetCode 网页编辑器用于日常提交，但我在复盘时更愿意把代码复制到本地，自己组织测试用例，跑一跑边界输入。本地的调试体验比网页强大得多，尤其是链表、树的深拷贝这类问题，不打断点真的很难一眼看出问题出在哪。

第二个是思维导图软件。每刷完一个分类，我会把这个分类的知识点、解题模板、易错点整理成一页思维导图。比如二分分类下，我会记录三种变体：第一种，在有序数组中查找一个数；第二种，查找满足条件的最小值（左边界）；第三种，查找满足条件的最大值（右边界）。每道题归类到对应变体下，复习的时候只看这一页图，效率比重新翻代码高得多。

第三个是一个简单的时间记录表格。我记录每道题的开始时间、结束时间、是否在 40 分钟内完成、卡壳的环节、以及参考题解后理解的程度。这个表格的价值在于，它能直观地告诉你哪类题型是你的弱项。我刷到第 40 天时，发现自己在二分边界问题上失手率极高，于是专门花了三天时间集中刷了十几道二分题，效果非常明显。人靠感觉记忆是不靠谱的，靠数据说话才能精准补短板。

5.3 心态管理：从“为什么我这么笨”到“这只是还没练到”

刷题过程中，最大的阻力不是题目本身，而是挫败感。我经历过那种 20 分钟毫无头绪、看了题解还是似懂非懂、关了浏览器再打开依然写不出来的感觉，特别容易让人怀疑自己。

后来我想明白一件事：算法题不像背书，它是一个技能型学科，而技能型学科的通病就是“当时懂了不算懂，能重复输出才算懂”。所以我现在面对一道做不出来的题时，会先给自己一个心理暗示：今天又多发现了一个知识盲区，这其实是赚了。然后我会把这道题拆开，告诉自己是卡在“想到用哪种算法”这一步，还是卡在“想到了但实现不出来”这一步。这两种卡点的解决方式完全不同，前者需要补题型模板，后者需要补代码基本功。

还有一个心态上的要点是：接受“反复遗忘”是正常现象。哪怕你昨天刚会做的题，今天复现时写不出来，也完全不丢人。人的记忆本来就需要多次刺激才能固化。刷题是一趟漫长的修路过程，不是一次性的填坑，允许自己忘、允许自己慢，只要方向是对的，进度慢一点根本没关系。

6. 接下来 50 天的方向：从“做过一遍”到“随时能写”

目前我的“面试经典 150”进度大概刷完了 80 道重点题，剩下的几十道大多是图论、复杂 DP 和难题这些硬骨头。接下来的 50 天，我不打算继续按题单顺序硬刷，而是改用“模块化封闭训练”的方式：先用三天时间集中攻克某一个分类，把这一个分类里的经典题全部刷完，再停一天做复现和总结，然后进入下一个分类。这样虽然一个分类只花几天，但知识的密度很高，容易形成整体记忆。

同时我会加大“模拟面试”的练习比重。具体做法是：每天挑一道题，限时 45 分钟，不开代码补全，不刷新网页，用一个纯文本文件从头到尾写完整代码，再自己设计测试用例验证。这个过程模拟的是真实面试的紧张感和反馈缺失，和平时做 LeetCode 题是完全不同的体验。我已经这样练了大约十天，最大的变化是，手写代码时的错误率下降了很多。

另一个方向是“二刷错题本”。我看了一下这 51 天的记录，真正值得二刷的题目大约有 25 道，这些是当时卡壳最严重、或者看了题解才勉强理解、理解后又花了两天才真正消化的题。二刷时我会尝试换一种解法来做，比如此前用 DP 的题，我会试着用记忆化搜索实现一遍；此前用中心扩展的回文题，我会试着用 Manacher 实现一遍。这样做的目的不是追求“会更多解法”，而是逼自己在不同视角之间切换，加深对知识点本身的理解。

我个人在实际操作中的体会是，刷题到中段最怕的不是题难，而是陷入“天天做题却感觉没进步”的麻木状态。这种状态一旦出现，最好的解药不是刷更多题，而是去做一套之前做过但已经快要忘记的题，或者干脆停下来写一篇阶段复盘。今天这篇复盘本身，是我给自己这 51 天的一个交代，也是给正在路上的人的一份参考资料。希望你在刷“面试经典 150”的时候，能从我这篇记录里找到一两句对你有用的话，哪怕只是一句“原来我不是一个人”，那也值了。