南瑾i“算法题打卡”进行到第三周，我反而比前两周更焦虑——不是怕题难，而是发现自己慢慢滑向了一种“看着题解觉得会了，合上答案自己写就卡壳”的危险状态。这篇复盘就从这里说起。我前两周刷题以“量”为主，每天逼自己过几道新题，打卡记录写得很满，但真正沉淀下来的不多。第三周我调整了策略：减少新题数量，把每道题做透、讲透，再顺手整理成笔记。为了不让打卡变成自我感动，这期我把三道题分别从暴力解法、最优解、以及实际提交时的翻车经历三个角度完整过了一遍，这篇就把整个过程拆给你们看。
这期内容不只是三道题的题解。我会把选型依据、边界条件、复杂度推导，还有提交时踩到的真实坑都铺开讲。适合刚接触算法刷题、正在做每日打卡的朋友，也适合刷了一段时间但总觉得“记不住、用不上”的人。
1. 我不把打卡当作任务：先想清楚三个问题再动手
1.1 打卡不是表演：这期我的训练目标是什么
前两周我打卡的输出来自一道“每日一题”，做完标记完成就算结束。到了第三周，我意识到这种做法有个明显的坏处：它让我在“见过”和“会用”之间划上了等号。我见到题面时觉得“这题我刷过”，但让我独立复述思路、手写代码、解释为什么这样做，往往卡住。这期我把标准提高到三个层次：
第一个层次是能讲清楚思路。不是为了面试时表演给面试官看，而是自己用大白话把解法从头到尾说一遍，说给自己听。如果哪一步说不顺，说明这里还没吃透。第二个层次是能在不看题解的情况下写对代码。这个门槛比想象中高，因为很多“会做”的题，一旦中间空一行、边界条件一变，手就停了。第三个层次是能说出解法的时间复杂度和空间复杂度，并且知道在哪一步产生了主要开销。能做到这一层，才算真正把题装进脑子里。
这期我挑了 12 道题作为打卡范围，覆盖链表操作、二叉树遍历、区间类问题三个主题。范围不算大，我的目标是每题都过一遍上面三个层次，而不是急着跳到第 13 道新题。最终挑选出的三道题是下面这一章里的内容。它们不是同一难度，但恰好能串起我对“边界条件”和“状态处理”的理解，也暴露了我几个很低级的错误。
1.2 环境与工具选择：提交前我先想清楚的几件事
刷题用什么语言，我的建议是两条腿走路：先用 Python 快速验证思路，再用一门静态类型语言（我平时用 Java）补一版。Python 适合快速把思路跑通，代码量小、不容易被类型问题干扰；Java 适合检查逻辑的严谨性，也顺带练习工程里常用的集合类。两条腿走的好处是在打卡时能同时锻炼两种语言的表达能力，不会出现面试时只会写伪代码的尴尬。
除了语言，我还给打卡固定了一套流程：看题后先不写代码，在纸上画输入输出示例，推导一两个非平凡用例；然后写暴力解，哪怕它是 O(n²) 也没关系；再在此基础上做优化。这个流程是我的一个习惯，此前踩过很多次“上来就写最优解，结果边界全错”的坑。
第三周开始，我还给每个打卡题目加了一栏“提交错误记录”。以前我只看最终通过的版本，现在我会把第一次提交错的代码和报错用例保存下来，过两天再回来看看错在哪。这栏内容成了这期复盘的重要素材，后面“翻车现场”那一章里会用到。工具本质上只是辅助，真正起作用的是这个“先想再写，写完再复盘”的循环。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本期拆解的三道题：从链表操作到区间合并
2.1 第一道：两个大数相加的链表实现
链表题里，我练得最多的是链表反转和合并，但第三周遇到的第一道题让我重新理解了“按位计算”的意义。题目描述很常见：两个非负整数分别用链表表示，链表的每个节点存一位数字，数字在链表中是逆序存储的，也就是个位在头节点。要求返回一个新的链表，表示两个数相加后的结果，同样逆序存储。
最直觉的想法是把两个链表分别读出来，拼成整数，相加，再转回链表。我确实先在本地这么写了，代码看起来能跑通简单的用例。但很快意识到一个问题：链表的长度不受限制，一旦数字超过普通语言整型的范围，这条路就废了。比如两个 100 位的数相加，如果用 int 存，早就溢出了。这正是本题存在的意义——它要的不是“把数读出来算完”，而是模拟手工列竖式的逐位进位过程。
于是最优解变成了一个模拟过程：同时遍历两个链表，每次取两个节点上的数字相加，再加上一个 carry 进位标志；当前位的结果就是 (v1 + v2 + carry) % 10，新的进位就是 (v1 + v2 + carry) // 10。循环一直执行到两个链表都走完，且进位也归零为止。
python复制def addTwoNumbers(l1, l2):
dummy = ListNode(0)
cur = dummy
carry = 0
while l1 or l2 or carry:
v1 = l1.val if l1 else 0
v2 = l2.val if l2 else 0
total = v1 + v2 + carry
carry = total // 10
cur.next = ListNode(total % 10)
cur = cur.next
if l1:
l1 = l1.next
if l2:
l2 = l2.next
return dummy.next
这里我特别想提醒一个细节：while 循环的条件必须包含 carry，不是 while l1 or l2。如果最后两位相加进位出 1，而两个链表都走完了，这个 carry 必须额外生成一个节点。我第一次写就是漏掉了这个条件，导致 999 + 1 这种用例直接丢掉了最高位。这个坑很经典，我建议打卡的朋友在做链表模拟时，第一件事就是把“循环结束后进位怎么处理”写在注释里。
复杂度上，这个解法只需要遍历一遍两个链表，时间复杂度 O(max(m, n))，额外空间只来自新链表本身，不计算输出空间的情况下是 O(1)。这个复杂度推导很直接，但真正在面试里能快速说清楚的人并没有想象中多。
2.2 第二道：二叉树的层序构造与遍历
二叉树的问题，我前两周刷了不少，遇到层序遍历时总爱用递归。这期我重新拿一道“按层输出二叉树节点值”的题来复盘，发现递归能做的层序遍历，用迭代加队列反而更贴合人类思考方式。题目要求很简单：给定一棵二叉树，返回逐层的节点值，第一层是一个数组，第二层是另一个数组，按从上到下的顺序排列。
最直观的解法是广度优先搜索（BFS）思想：用一个队列装节点，初始把根节点放进去。每轮循环先记录当前队列的长度 n，这一步非常关键，因为 n 代表当前层有多少个节点。然后从队列头部连续弹出 n 次，每弹一次就把它的左右孩子加进队列。等这 n 次弹完，当前层的数组就收集完了，而队列里的新内容恰好是下一层的全部节点。
python复制def levelOrder(root):
if not root:
return []
from collections import deque
q = deque([root])
res = []
while q:
level = []
for _ in range(len(q)):
node = q.popleft()
level.append(node.val)
if node.left:
q.append(node.left)
if node.right:
q.append(node.right)
res.append(level)
return res
我用递归也写过一版，思路是维护一个 level 参数，递归进入左子树或右子树时让 level + 1，再把节点值挂到对应层级的数组里。这个做法在思路上更“数学”，但对很多人来说不够直观，而且如果树非常深，递归层数可能成为问题。相比之下，迭代版用一个显式的队列，把“下一层的信息”直接保存在了队列里，不必担心调用栈深度。
这道题让我重新意识到一个点：很多二叉树问题用递归写非常漂亮，但它的物理基础是调用栈。打卡练习时最好常见题型都分别准备递归版和迭代版，因为面试中面试官常常会追问“如果递归深度过深怎么办”。能当场把递归改成迭代，是很加分的表现，也是一种通用能力。
复杂度层面，每个节点恰好进队一次、出队一次，时间 O(n)，空间上队列最多同时保存一整层的节点，最坏情况也就是 O(n)。
2.3 第三道：合并重叠区间的双指针思路
第三道题是“给定若干个区间，合并其中重叠的部分”。比如输入 [[1,3],[2,6],[8,10],[15,18]]，合并后应该是 [[1,6],[8,10],[15,18]]。这题应用场景很直观，日程安排、可用时间窗合并、服务器资源区间合并等，都是同一个模型。
我最初遇到这题时，脑子里冒出来的方案是先两两比较，只要有重叠就合并，然后循环直到没有重叠为止。这种思路的复杂度很差，而且代码容易写得又长又绕。实际上，合并区间有一个很简单的前提：如果区间已经按左端点排好序，那么合并过程就可以只从左往右扫一遍。
排序之后，维护一个结果列表 res。把第一个区间放进去，然后遍历剩下的区间。对于当前区间 [a, b]，取结果列表最后一个元素 [lastStart, lastEnd]，判断它们是否重叠：如果 a <= lastEnd，说明当前区间会被合并进上一个结果区间，新的右端点取 max(lastEnd, b)；如果 a > lastEnd，说明没有重叠，直接作为新的结果追加进去。
python复制def merge(intervals):
if not intervals:
return []
intervals.sort(key=lambda x: x[0])
res = [intervals[0]]
for i in range(1, len(intervals)):
cur = intervals[i]
if cur[0] <= res[-1][1]:
res[-1][1] = max(res[-1][1], cur[1])
else:
res.append(cur)
return res
这里最常见的误区是用 cur[1] 直接覆盖 res[-1][1]。如果后一个区间的右端点比前一个大，覆盖没问题；但如果后面那个区间完全被前一个大区间包含，比如 [1, 7] 和 [2, 3]，直接覆盖就会让结果变成 [1, 3]，这显然是错的。正确做法是取 max(lastEnd, curEnd)，这也是合并区间问题里最容易翻车的地方。
排序是这道题性能的主要来源，使用 O(n log n) 的比较排序，后面的线性扫描是 O(n)，总体就是 O(n log n)。空间上，如果结果列表不算额外空间，只用到常数级的额外变量，那就是 O(1)。
3. 现场翻车记录：区间合并题的排序坑与边界处理
3.1 翻车现场：一个很隐蔽的错误用例
这期打卡里让我最印象深刻的翻车，不在解题思路上，而在一个我完全没预料到的地方——排序比较器的溢出问题。我先把 Python 版跑通了，结果符合预期。按习惯，我再用 Java 补一版，提交时却在一个看起来非常简单的用例上挂了。
当时的测试用例大概是这样的：[[-2147483648, 0], [1, 3], [2, 6]]。看起来没有任何问题：第一个区间左端点非常小，右端点是 0；后面两个区间是重叠的。按 Python 版逻辑，排序后第一个区间 [-2147483648, 0] 在开头，然后遇到 [1, 3]，发现 1 > 0 不重叠，直接追加；再遇到 [2, 6]，它和 [1, 3] 重叠，合并成 [1, 6]。结果应该是 [[-2147483648, 0], [1, 6]]。
但 Java 版输出却是乱的，合并结果完全不对。我当时的第一反应是合并逻辑写错了，把 max 写成了直接覆盖。可检查了好几遍，代码逻辑和 Python 版一模一样。于是我开始打印排序后的中间结果，发现排序后的顺序根本不是预期中的顺序，[-2147483648, 0] 并没有被排到第一位。
3.2 定位到根因：比较器里不能用减法
问题出在 Java 的排序比较器。我写的是这样一段代码：
java复制Arrays.sort(intervals, (a, b) -> a[0] - b[0]);
看起来没有任何问题，按照左端点升序排列，返回差值不是挺自然的吗？问题在于，Java 的 Comparator 返回的是 int，而 a[0] - b[0] 在极端值面前会溢出。-2147483648 - 1 这个减法结果超过 int 范围，成了一个很大的正数，于是比较器告诉排序算法“这个很小的左端点应该排到后面去”，顺序自然就错了。
这就是为什么在写 Java 比较器时，永远不要用“差值”作为返回值。安全写法是分段比较，或者直接调用包装类的比较方法：
java复制Arrays.sort(intervals, (a, b) -> Integer.compare(a[0], b[0]));
// 或者
Arrays.sort(intervals, Comparator.comparingInt(a -> a[0]));
我用 Integer.compare(a[0], b[0]) 替换之后，排序立刻恢复正常，合并结果也正确了。这个坑让我意识到，Python 的 sort(key=...) 底层帮你屏蔽了很多细节，但也正因为这样，我在写 Java 时没有建立起“比较器返回值是 int，差值会溢出”的意识。在工程实践中，这种错误不只是刷题才会遇到；任何需要排序的业务代码都可能因为用户输入触碰到边界值而翻车。
3.3 修完还没完：溢出问题背后的稳定性思考
修完 Integer.compare 之后，我没有直接跳到下一题，而是继续想了一遍：这个坑还有没有别的变体？有的，比如 Math.abs 相关的问题。有人在排序时为了按差值排序，会写 (a, b) -> Math.abs(a[0]) - Math.abs(b[0])，同样存在溢出风险。只要“计算结果的数值范围超出 int 可表示的范围”，比较器就不可靠。
还有另一个容易忽略的点：Comparator 返回值约定是负值、零、正值分别代表小于、等于、大于。如果你返回了一个不合法的值，排序算法不会报错，它只会按照你给的“错误提示”进行调整，最终得到一个不合法的顺序。最可怕的是，这种错误通常只在边界用例出现，普通用例往往一切正常，所以很容易被忽视。
顺着这个思路，我又检查了自己其他 Java 代码里所有自定义比较器，凡是写成 return a - b 的地方，一律改成 Integer.compare 或 Long.compare。这是我第三周打卡里最有价值的一次排查，它提醒我：刷题不一定每次都是“题目本身难”，有时难在语言工具在你忽视的地方设下的暗礁。
4. 题刷完之后必须要做的三件事：复杂度复盘、测试用例补齐、错题标记
4.1 复杂度复盘：从 O(n²) 到 O(n log n) 的思考过程
第三周打卡让我养成了一个习惯：每道题至少写两个版本的解法，一个暴力版，一个优化版，然后把两者的复杂度写在笔记里对比。拿上面合并区间来说，暴力版的思路是每次选一个区间，和结果列表中所有已有区间比较，能合就合，不能合就继续。最坏情况下，每次比较都可能需要扫描结果列表，整体复杂度会到 O(n²)。而排序后一次扫描是 O(n log n) + O(n)，在这个问题里明显更优。
但复杂度对比不能只看最终结果，还要看常数项和数据规模。如果 n 很小，暴力版的常数项低，实际执行未必比排序版慢。很多初学者拿到“最优解”就万事大吉，却没有想过它为什么最优、在什么条件下最优——这种思考能力恰恰是真正做事时区分水平的地方。
我在打卡笔记里会给每道题建立一个小表格，内容包括：题号、题目类型、暴力解复杂度、最优解复杂度、第一次提交是否通过、错在哪。第三周结束后我统计了一下，12 道题里有 7 道第一次提交就通过了，另外 5 道各有各的问题。其中 3 道是边界条件写错，1 道是溢出问题，1 道是完全没思路（看了题解）。这个统计本身就有价值，它能告诉你当前短板到底在哪里。
4.2 测试用例的设计：不是跑一遍就完
刚开始打卡的时候，我用“题目自带的示例”测试完，一旦通过就提交。第三周我专门训练自己“构造测试用例”的能力。比如做链表求和时，我会主动测 [9,9,9] + [1] 这种会产生连续进位的用例；做合并区间时，我会测 [[1,4],[0,4]] 这种左端点无序的情况，以及 [[1,4],[2,3]] 这种包含关系。
构造测试用例的方法论其实不复杂，就是盯住三个方向：边界值、空值、极端输入。边界值包括空链表、空数组、单节点、只有一层、左右子树为空等情况；空值包括 null 根节点、空区间；极端输入包括极大极小整数、超长链表、退化成一串的二叉树。把这些用例列成一个小清单，每道题都用它们过一遍，往往能提前发现一半以上的隐藏问题。
我还试过一个小技巧：先不看最终代码，只根据题面写几个自己凭直觉构造的用例，把它们作为预期结果记在纸上；然后把代码跑起来，用同样的用例去测。如果结果和预期不一致，就说明代码的行为和自己的理解有偏差。这个方法会逼迫你去面对“原来我根本没理解题意”的尴尬时刻，但也是记忆最深刻的时刻。
4.3 错题标记与回头看
我用了一个很简单的办法管理自己的错题：在打卡笔记中给每道题加一个标签，分为“一次通过”“边界翻了”“思路卡壳”“完全不会”四类。每周结束时，只看后两类题目，不看新题。这个“回头看”的做法让我的复习不再是一笔糊涂账，而是有明确的目标。
“完全不会”的那道题，我记录下了当时卡住的具体位置。比如题目要求“在有序数组中查找目标值的插入位置”，我知道要用二分，但边界条件怎么设置、left 和 right 怎么更新，当场全乱了。我把这个过程写下来后，隔三天再重新做，秒过——因为当时卡住的那个结点，已经变成了笔记里的红色标注。
打卡的意义不在于“连续打卡第多少天”，而在于每一天有没有留下一点可以拿出来再用的东西。对我来说，这个“东西”就是错题集和复杂度笔记。连续天数断了也不用焦虑，真正的记录是看掌握了多少，不是看断没断签。
5. 关于打卡节奏的一些个人经验
5.1 每天几题合适：量变与质变
第三周我试过一天 5 道新题的节奏，也试过一天只精做 2 道题加 1 道复习的节奏。对比下来，后者的吸收效果明显更好。原因也不复杂：新题做得多，意味着每道题分到的时间少，思考深度就浅；而旧题复习时，大脑需要重新组织一遍“为什么当时错”“现在应该怎么写”，这个重新组织的过程本身就是加深理解的过程。
如果你也在做类似的打卡，我的建议是：不要把所有时间都拿去做新题。每周至少留出两个时段专门复习本周错题，哪怕一道题只有 20 分钟，也比再做五道新题有用。量变确实能引起质变，但这个质变的前提是你记得住之前的“量”。如果做完就忘，那等于没做。
我一般把每天打卡时间控制在 1 小时左右：前 15 分钟复习一道旧题，中间 30 分钟精做一道新题，最后 15 分钟整理笔记。这个节奏没有固定标准，但它帮我稳定度过了一个月的刷题周期而没产生严重倦怠感。长期维持比单日冲量重要得多。
5.2 怎么克服“看题解就会，上手就废”
这是我前两周最大的痛点。看到题解时每一步都合理，觉得“这不难”，但合上题解自己要写，立刻不知道从哪一句开始。后来我发现，问题出在“被动输入”和“主动输出”的差异上。看题解是被动接收信息，大脑会误以为“理解”等于“能做”；而实际写代码是主动构造，需要你自己决定每一步的顺序、边界和命名。
破解方法只有一个：看完题解后不要马上照着敲代码，先把题解合上，用纸笔把核心思路写出来，包括用哪个数据结构、循环条件是什么、边界怎么处理，写到“自己觉得可以开始写代码”为止。这个写思路的过程就是强制转换模式，从“接收者”变成“构造者”。
我自己还有一个辅助手段：给每道题写一句“一句话思路”。比如链表求和那题，我写的是“双链表同时走，遇到空节点当 0 处理；用 carry 记进位，最后若 carry 不为 0 要补一个节点”。下次看到这道题，先看这句话，再自己补充细节。这比直接背代码靠谱得多，因为背代码会随着遗忘曲线迅速衰减，而“一句话思路+自己推导细节”能留存很久。
5.3 我踩过的坑，给你留一份清单
把周期内遇到的问题汇总一下，最典型的是这几个：
第一，忘记处理空输入。很多题目如果输入为空，应该直接返回空结果或空链表，但我在快速写代码时经常下意识跳过这个分支，导致提交后报空指针或越界。解决办法是在写代码前先问自己一句“如果输入是空，这个函数应该返回什么”。
第二，合并区间时不取 max，直接覆盖右端点。这道题的坑我在前面详细讲过了，属于逻辑不严谨造成的。它提醒我：凡是“合并”“更新”类操作，要仔细想清楚是“直接赋值”还是“取极值”。
第三，Java 比较器里用减法判断大小，忽略了整数溢出。这个坑直接导致了一次提交失败，值得单独拿出来再强调一遍。写完 Comparator 后不要急着提交，先看一眼有没有 return a - b 这种危险写法。
第四，递归和迭代分不清适用场景。二叉树题我习惯性用递归，但当树很深时会担心调用栈溢出。遇到这种问题，我现在会刻意要求自己先用迭代实现一遍，编解码的过程也是训练。
第五，盲目刷题不做复盘。这个坑不是某道题的问题，而是一个周期性的问题。如果你发现自己刷了一百道题，再回到 20 天前做过的题目时还会卡壳，说明复盘环节没跟上。这时候应该停一下新题，集中把旧题重新过一遍，不要为了保持“连续打卡”而牺牲实际吸收率。
打卡的第 21 天，我回头翻看这周做的三道题的笔记，发现第一周写的很多东西现在能看懂当时的错误，也能看出明显的进步。这种“看得到的变化”带来的满足感，比“数字上的连续天数”真实得多。如果你也在为自己的刷题节奏焦虑，不妨把标准从“今天又做了几道新题”改成“今天有没有从旧题里学到新东西”。这个改动很小，但它让我的打卡真正变成了自己的积累。