我给自己挖了个坑，然后非常守信用地把坑填完了——填的就是这篇名为《从零开始学力扣（中道崩殂版）》的复盘记录。
刷题这件事，网上的攻略一抓一大把，什么"三个月冲进大厂""Hot 100 刷三遍保你面试无忧"，看得人热血沸腾。但很少有人愿意坦白说：我刷着刷着，刷不动了。不是题太难，是人先崩了。我决定把这个"人先崩了"的过程原原本本写出来。如果你是刚开始想刷力扣的新手，或者正在崩溃边缘挣扎，这篇内容应该能让你少走几个月的弯路。
1. 先说清楚：这个项目到底是什么
光看标题，你可能觉得这是又一个"刷题劝退贴"。其实不是。这更像是我的个人项目记录，项目名称就叫"从零开始学力扣"，但最终交付物不是"刷完多少题"的成就清单，而是一份诚实的、带血的、实操性极强的落地方案——只是这个方案在"每天刷 2 小时"的计划执行到第 47 天的时候，宣布阶段性暂停，也就是标题里说的"中道崩殂"。
1.1 "从零开始学力扣"的完整背景
先说下我自己的起点，不然你没法理解后面为什么会崩。
我本职是做业务系统开发的，Java 为主，日常写代码没问题，CRUD 用得飞起，但基本没有接触过严格意义上的算法训练。大学学过数据结构，但那是七八年前的事了，图的遍历、动态规划对我来说基本等于只记得名字。决定刷力扣的导火索很现实：准备看机会，想进一家技术氛围更浓的团队，也知道如今面试算法题几乎是标配，绕不过去。
"从零开始"这四个字，我当时想得太简单了。我以为的从零，是"从最简单的题开始刷"。实际上的从零，是从"连力扣的编辑器都不会用"开始。我第一次在力扣网页上写代码，连输入输出的样例格式都看了半天，更别提那些 Top 1%，击败 99% 提交者的花式解法了。
1.2 为什么是"中道崩殂"而不是"坚持到底"
这是整个项目里最关键的定性。
"中道崩殂"在我们的语境里通常带着点自嘲和遗憾。但我特意用"崩殂"，想强调的是：这段经历没有白费。它以一种惨烈的方式，让我看清了刷题这件事的真实面貌——刷题不是靠一腔热血能赢的，它需要更系统的策略、更诚实的自我评估，以及更明确的阶段目标。
我没有彻底放弃刷题，而是放弃了"从零开始学力扣"这个宏大而模糊的项目，换成了"每天只刷一道简单题，不加任何KPI"的低压模式。也就是说，第一版项目崩了，但崩完之后我重新搭了个能跑的小项目。这可能是这篇文章对你最有价值的部分——你不需要重复我崩掉的过程，直接拿走我重建之后的方案就行。
2. 开局设想：一份看起来完美无缺的刷题计划
每个崩掉的项目，都有一份精美的计划书。我也不例外。在正式打开力扣官网之前，我花了整整一个周末，做了一份让自己都感动到不行的计划。
2.1 目标设定：Hot 100 与热题 100 的双线推进
我的核心目标非常明确：刷完力扣热题 100，同时结合最新的力扣热门题目清单（也就是大家常说的 Hot 100）双线推进。当时的逻辑是，Hot 100 是面试高频题的精筛，无论面什么公司，把这 100 题吃透，至少能应对大部分算法环节。
我甚至做了一张 Excel 表格，把 Hot 100 里的题目按标签全部分好类，哈希、双指针、滑动窗口、二叉树、动态规划、贪心……还用不同颜色标出了"已计划""进行中""待复习"。第一版的计划特别唬人：每天 2 道新题，周末补 2 道复习，30 天刷完前 50 题，60 天整体过一遍，第 70 天开始二刷。
听起来是不是很合理？问题是，这份计划从头到尾只有"刷题"这个动作，没有考虑"不会做""看不懂题解""写出来但超时"这些真实存在于刷题过程中的阻力。一个真正的计划，应当把"卡住的时间"也计算进去。我当时的计划，相当于默认了每道题都会在自己的控制范围内按预期推进，这个假设从一开始就是错的。
2.2 语言选型：为什么选了 Java 刷力扣
作为一个业务出身、日常写 Java 的人，选 Java 刷题几乎不用思考。Java 的生态我太熟悉了，不需要边刷题边查语法。而且 Java 在力扣上有几个天然优势：丰富的集合类，比如 HashMap、HashSet、PriorityQueue 直接当堆用；StringBuilder 处理字符串拼接；Arrays 工具类的排序、拷贝。这些 API 能让核心算法的实现变得相当清爽。
但 Java 也有很烦人的地方。比如刷到树的题目，力扣给的是 TreeNode 定义，你得自己搞清楚引用关系；刷到链表的题，得时刻注意空指针。C++ 选手可能更奔放，直接用指针硬刚，Java 就得老老实实搞对象引用。更扎心的是，Java 的代码在力扣上的耗时通常比 C/C++ 长一点，有时候同样的思路，Java 就是踩在超时边缘。
我没换语言，因为换语言的成本远大于它可能带来的收益。新手选刷题语言就一条标准：哪门语言你写得最熟就选哪门，不要为了"性能更好""大佬都用它"去学一门新语言来刷题，那样等于同时学两件事，必崩。
2.3 时间安排：每天 2 小时与"可行性"幻觉
我给自己定的时间安排是：工作日每天晚上 2 小时，周末每天 3 到 4 小时。加起来一周接近 18 小时，怎么看都够用。真实情况是，我的"每天 2 小时"平均要打五折。下班到家已经八点多，吃完饭歇一会儿，坐到电脑前最快也要九点。刷题这件事还有一个巨大的陷阱——它不是打开网页就开始的。
你需要先读题，读一遍没读懂，读两遍。然后开始想思路，想不出来，翻题解。题解不是一个字一个字看完就完了，你得理解，得验证，得自己敲一遍，敲完发现提交报错，再看错误样例，改，再提交。这么一套流程下来，2 小时只够刷一道题，而且不是那种"游刃有余地刷完还能总结"的状态，而是"勉强看懂别人怎么解"的状态。
我后来算过一笔账：按照我真实的效率，完成 Hot 100 的第一遍大约需要 250 到 300 小时，而不是计划的 150 小时。这个误差直接决定了项目的崩盘节奏——计划越宏伟，落差越崩溃。
3. 实战记录：从某一次的蜜月期到逐渐崩溃的真实刷题过程
计划归计划，真正让我一个字一个字写下这篇复盘的，是那些实打实坐在电脑前、面对编辑器里闪烁光标的夜晚。这段过程大概可以分成三个阶段。
3.1 前两周的热恋期：数组、双指针、简单题带来的虚假繁荣
刷题的头两周，体验其实相当好。我从 Hot 100 里最容易的标签开始：哈希、数组、双指针。这类题目的共同点是"不需要你发明一个算法，只需要你熟练掌握一种套路"。
最简单的例子是两数之和。第一次提交通过的那一刻，我激动得截图发了朋友圈。不是说这道题有多难，而是那种"原来力扣题也可以做出来"的正反馈太强了。紧随其后的有效的括号、合并两个有序链表、移动零，每道题都让我觉得自己离"算法大神"只差 100 道题的距离。
现在回头看，这就是典型的"虚假繁荣"。这些简单题本质上是在验证你已经会的东西，而不是教你的东西。它们能让你获得成就感，但不会让你的算法能力产生质变。真正的挑战——树的遍历变种、回溯的剪枝、动态规划的状态推导——还安静地躲在 Hot 100 的中后段，等着给我当头一棒。
3.2 第一次心态波动：动态规划的"我懂了"陷阱
大约刷到第 25 题左右，我开始遇到动态规划。这也是我整个刷题过程中第一个真正意义上的坎。
当时遇到的是爬楼梯的变种和打家劫舍。这两道题在动态规划里已经算温和的了。我照着题解写，写出了"状态转移方程"这几个字，那一刻，我真的觉得自己懂了。状态转移方程就是这个啊，把大问题拆成小问题，用之前的答案推导现在的答案，逻辑通顺，代码简洁，运行效率高。我还专门做了笔记，画了图，把每一步都整理得清清楚楚。
然后我合上笔记，关掉题解，重新打开一个新的动态规划题目——完全不会。问题出在，我在"阅读题解"的时候，以为自己是在"理解算法"。实际上，我只是在"顺着别人的思路走了一遍"。动态规划最核心的能力是"从零推导出状态定义和转移方程"，这个能力我没练过。我看懂了别人的推导过程，不代表我自己面对一个新问题能够完成这种推导。
这种感觉就像你看完了一百个魔术解密视频，觉得自己已经是魔术大师了，但上台表演的时候，手还是抖的。我对动态规划题产生了畏惧心理，越畏惧越不想碰，越不碰就越生疏，形成了一个负循环。
3.3 终极崩溃现场：三维接雨水是怎么把我劝退的
如果有什么题目可以称为我这次刷题之路的"终点站"，那一定是三维接雨水（力扣 407 题，Trapping Rain Water II）。这道题在热门题目里讨论度一直很高，不少分享帖把它列为"尽力而为，不会也正常"的难度。
先说说这道题让人崩溃的点。二维版本的接雨水（第 42 题），你面对的是一个一维数组，只需要思考每个位置能接多少水，经典的"左右最大值取较小值"思路就能搞定，双指针 O(n) 遍历一遍，空间 O(1)，简洁优美。但三维版完全不是一个量级：你面对的是一个二维矩阵，每个格子有自己的高度，雨水可以从上下左右四个方向流动，最外圈不能蓄水，但内部的凹坑能蓄多少水，取决于它四周所有方向上最低的"缺口"。
我第一次看到这道题的时候，盯着题目描述看了十分钟，脑子里一片空白。我知道这题要用优先队列（Java 里的 PriorityQueue ），也隐约知道反向思路是"从边界向内收紧"——但问题是，为什么要从边界开始？为什么每次要弹出最小高度的格子？弹出的格子高度和蓄水量到底是什么关系？我把题解反复读了三遍，每句话都认识，放在一起就是理解不了。
那天晚上我做了个决定：先跳过，明天再看。第二天还是不会。第三天，我花了整整三个小时，像小学生抄写课文一样，把别人的解法一行一行敲进编辑器，提交通过。但我清楚，我只是用 Java 复述了一遍别人的思路。如果面试官让我在白板上手写这道题，我绝对写不出来。这种"做了等于没做"的挫败感，是我最终决定踩下刹车、承认这个项目需要重构的直接原因。
4. 复盘：我踩过的坑，希望你一个都别踩
项目停了之后，我没有立刻放弃，而是花了几天时间，把自己从决定刷题第一天开始的所有经历做了一次完整复盘。三个层面的问题看得清清楚楚。
4.1 计划层面的三大误区
第一大误区是"用理想速度计算真实工期"。我原计划 60 天完成 Hot 100 第一遍，但真实推进中，简单题可能 20 分钟就过，中等题平均要 1 到 2 小时，难题可能会耗掉一整个晚上甚至更久。正确的估算方式是：先刷 10 道题，统计自己的平均耗时，用这个真实数据来计算总工期，而不是用列表上的题目数量去乘一个幻想中的"每天 2 道"。
第二大误区是"没有给卡住留缓冲"。刷题不像跑步，今天的 5 公里跑完了就是跑完了。刷题存在一种极端情况：一道题卡了两天，进度停摆，之前计划好的后续题目全部顺延。一旦出现顺延，整个计划表就开始失去意义，然后焦虑感开始累积。所以计划里必须内置"卡题缓冲日"，比如每周留一天只做复习和重刷，不安排新题。这个缓冲日，不是可选的，是必须的。
第三大误区是"把刷完等同于学会"。我当时的目标是"刷完 100 题"，这个目标本身就注定了翻车。刷题的正确目标应该是"掌握 N 种算法思想，并且在随机抽查时依然能独立解出题目"。题目数量的指标太容易作弊了——抄题解、背代码、跳过不懂的难点，都可以让数字增长，但能力不会跟着增长。
4.2 方法层面的五个致命错误
第一个方法错误：不复习就刷新题，等于一边加水一边漏水。我当时刷到第 40 题的时候，回头发现第 10 题的解法已经很模糊了。算法这东西，遗忘曲线极其陡峭。正确做法是按 1 天、3 天、7 天、15 天的间隔反复复习已经做过的题，并且复习时要求自己不看题解独立完成。
第二个方法错误：只做新题不做总结。我前 30 题的笔记，本质上是"题解代码的搬运工"。我没有总结过"双指针类题目的共同特征""回溯算法的通用模板""动态规划的思考步骤"。没有这些总结，我刷的题就是一座座孤岛，无法形成迁移能力。
第三个方法错误：死磕难题，挫败感吞噬信心。三维接雨水这种 Hard 题，应该学会"战略性放弃"或者"看懂题解后过几天再独立重写"，而不是当场死磕。死磕的唯一结果就是浪费大量时间并严重打击自信心。
第四个方法错误：频繁换题单，永远在找"最全攻略"。刷到中途，我因为焦虑，开始刷各种"力扣刷题攻略"，想找到一条更轻松的路径。结果就是浪费了很多时间在对比攻略、重新规划上，实际刷题时间反而减少了。后来我才明白，任何一份主流攻略都有可取之处，选一个跟到底，胜过反复横跳。
第五个方法错误：忽视语言本身的 API 熟练度。用 Java 刷题，其实需要非常熟悉集合框架的各种边界行为，比如 PriorityQueue 默认是小顶堆，自定义比较器时要小心溢出，HashMap 的 computeIfAbsent 能简化代码但用不好容易迷惑。我在刷题过程中不止一次因为 Java API 不熟而卡壳，这其实也可以通过专项练习来补。
4.3 心态层面的两个无解问题
心态问题比方法问题更难解决。第一个是"同辈压力"。我的刷题群里，永远有人一天刷 5 道题，永远有人发"三周刷完 200 题"的经验贴。这种东西看多了，真的会让人产生强烈的焦虑和自我怀疑。我现在想明白了：别人的进度是别人的，基础不同、时间不同、目标不同、语言不同，根本没有可比性。刷题这件事上，唯一的比较对象就是昨天的自己。
第二个心态问题是"完美主义后遗症"。当我意识到自己无法按照原计划完美执行时，我的第一反应不是调整计划，而是产生了一种"既然无法完美完成，那就干脆不做了"的逃避心态。这是很多人中途放弃的心理根源。应对方式只有一个：在计划落地时就把"不完美"当成默认选项，允许自己偶尔断档，允许自己跳过难题，允许自己在状态不好的时候只复习一道旧题。这些"允许"不是放纵，而是对自己人性真相的尊重。
5. "继承"与重建：崩殂之后，我用这几个操作重新上桌
如果这篇文章只是写我怎么放弃的，那它顶多算一篇情绪日记。真正的价值在最后这一段：项目崩了之后，我做了什么调整，以及如果你也准备刷力扣，可以直接复制的路线。
5.1 我做的第一个动作：砍掉目标，留下习惯
"中道崩殂"的直接原因，是项目本身承载了太多 KPI：30 天完成多少题、多少天内二刷、每题都要独立想出来……我做的第一个调整是把这些目标全砍掉，只保留一个最微小的动作：每天打开力扣，做一道题。题目难度不限，哪怕只是做一道之前做过的简单题都算完成。
这个调整的作用非常明显。因为任务足够小，小到没有任何心理负担，所以几乎不会找借口偷懒。我保持了每天做题的节奏，虽然整体进度大大放慢了，但这个节奏本身就是最大的成果。等到节奏稳定之后，系统会给你一种惯性，你再想进阶加量，就顺理成章了。
5.2 第二个动作：按专题刷，而不是按题目编号刷
之前我几乎是按照 Hot 100 默认排列顺序来刷，一会儿链表一会儿动态规划，知识结构散成一片。重启之后，我把方式改成"按专题推进"：这个星期只做双指针，下个星期只做二叉树，做完一个专题就总结一个专题的通用模板。
这个改动的价值太大了。当一个专题的题目集中出现时，你会发现它们背后的套路高度相似。就像双指针，核心无非是"左右指针从两端向中间逼近"或"快慢指针从头同步前进"，你连续做十道双指针题，自然就形成肌肉记忆了。按专题刷，其实是在帮你建立一个又一个清晰的知识模块，而不是让知识点杂乱地散落在你的大脑里。
5.3 第三个动作：把"题解阅读"升级为"独立复现"
这是我在复盘阶段最受益的一个改变。以前看题解，是"看了之后点头，觉得好有道理"。重启之后，我给自己立了一条铁律：题解只看思路，不看代码。看完思路之后，合上题解，自己在编辑器里独立把代码写出来。写不出来就再看思路，再合上，直到能独立写出来为止。
这个过程的体验完全不一样。当你被迫从零开始组织逻辑时，你才会真正暴露出自己理解上的盲区。你以为自己懂了"用栈维护一个单调递减序列"，但动手写的时候，你才会发现你根本不知道栈里应该存下标还是存值、什么时候 pop、什么时候计算面积。独立复现有个残酷又有效的检验标准：关闭所有参考，打开一个新窗口，如果你能完整写出来并且提交通过，你才勉强算是"见过了这道题"。
5.4 给新手的最终忠告：接受"中道崩殂"也是项目的一部分
最后说点掏心窝子的话。
如果你正在刷力扣，或者准备开始刷，我的建议不是"你一定要坚持到底"，而是"允许自己的进度不如预期"。刷题本质上是长期主义者的游戏，短期的"崩殂"不是失败，它只是你在探索边界的时候撞到了一面墙。墙没有错，你也没有错，错的是那个以为"只要撞墙就能穿过去"的计划。
我个人更倾向的做法是：每刷 20 道题，就做一次阶段性复盘，看看哪些类型的题让你耗时最多、哪些知识模块你始终没有建立起来。如果发现某个专题让你反复崩溃，就大方地把它标记为"暂缓攻坚"，先并行推进其他更顺手的内容。等你的信心池子蓄满了，再回头啃硬骨头，胜率会高很多。
我现在依然保持着每天刷题的节奏，但心态已经完全变了——不再为了赶进度，也不再追求"所有题我都会"。对我这个业务开发出身的人来说，刷力扣最大的意义，是在不断解决抽象问题的过程中，保持思维灵活度。至于 Hot 100 有没有刷完，说实话，已经不重要了。重要的是，我还在刷，并且这一次，不会再崩了。
