OJ有效练习指南：从无效刷题到可迁移解题能力

刷OJ的朋友，不管是刚入门的在校生，还是已经在准备校招的准毕业生，应该都遇到过这种状态：题目没少刷，网站上的提交记录一大片，可一到新题面前，脑子还是空白。每天打开 OJ 系统，跟打卡一样做两道Easy题，自我感觉挺充实，但真到了笔试或者比赛，被一道变形题直接打回原形。问题出在哪？我自己的体会是，把“刷题”和“练习”混为一谈了。刷是数量逻辑，练是质量逻辑。这篇想聊的，就是围绕 OJ 题目练习这件事，怎么把无效的提交记录，变成真正能迁移到新题、笔试、甚至工程问题上的能力。内容会涉及选题策略、单题拆解流程、卡壳时的调试思路，以及如何把一套题目转化成自己的方法论，适用于准备华为 OJ、学校自建 OJ（比如东华 OJ）这类平台，或者主流国际 OJ 的读者。

先用一句话说清楚我的立场：OJ 练习的本质不是“做过多少题”，而是“建立多少可复用的解题模式”。所以这篇不是给你罗列刷题清单，也不是推荐哪家 OJ 平台更好——而是复盘我自己从乱刷到系统练，从看题解到独立 AC 的完整转变过程。不管你现在处在哪个阶段，这篇都值得你花十分钟认真读完，然后重新规划一下自己的练习方式。

1. 为什么刷了500道题，遇到新题还是没思路

这是一个特别普遍，又特别打击人的现象。我见过很多同学，LeetCode 刷了三四百，学校 OJ（比如东华 OJ 那种教学平台）上的平时分也拿得挺高，但一参加华为 OD 机考或者大厂笔试，遇到中等偏上的新题就卡住。真正的根源，通常不是题量不够，而是练习方式出了问题。

1.1 你是在“回忆解法”，不是在“推导解法”

大多数人刷题的路径是这样的：打开题目，读一遍，有点眼熟，但想不起来具体怎么做，于是翻开题解，“哦，原来是 DP（动态规划）”，然后照着官方思路把代码敲一遍，通过了，下一题。这个过程表面上是做题，实际上是在做“解法誊写”。脑子里的记忆点只有一个模糊的“这题像某某题”，而不是“我为什么能想到用 DP，状态怎么定义，转移方程怎么来的”。

一个比较反直觉但很真实的判断标准是：如果你 AC 一道题之后，隔一周把代码删掉，重新面对同样一道题，你还能不能独立写出完整的推导过程？如果能，这道题才算真正进了你的脑子。如果不能，这道题对你的帮助约等于零，甚至还会造成一种虚假的成就感，让你误以为自己已经掌握了一类题型。

我自己改变这个问题的第一个动作，是把所有的刷题行为从“看完题解再写代码”，强制改成“先独立思考至少三十分钟，哪怕最终没有完全 AC，也必须先把自己的错误思路完整写出来”。这个过程非常痛苦，前期效率会肉眼可见地下降，可能以前一天刷十道，现在一天只能啃一两道。但坚持两三个月之后，效果会开始显现——你会发现自己对新题的第一反应不再是“我好像没见过”，而是“这道题跟某某模式有关，我先试试从这个角度切入”。

1.2 分类刷题的真正目的，不是记住套路，而是抽象模式

还有一种无效刷法是“按标签刷”。今天刷动态规划，明天刷贪心，后天刷图论。听起来很有体系，但如果你只是把这个专题的题目挨个做一遍，没有做一件关键的事——对每道题抽象出“它属于该专题下的哪个分支，分支和分支之间靠什么区分”——那专题刷完，留下来的依然是碎片。

举个例子。同样是动态规划，背包问题、最长递增子序列、区间 DP、状态压缩 DP，它们虽然都叫 DP，但解题切入点和复杂度模型完全不同。如果你只停留在“这是 DP 题”的粒度上，那到了考场，你只能做到“知道要用 DP”，但说不出“到底是哪种 DP、状态怎么设计、需不需要优化”。

我的做法是每做完一道题，都用一两句话给自己写一个“模式标签”，例如“二维网格从左上到右下的路径计数，无障碍版本是组合数，有障碍版本是 DP；DP 的状态是到达 (i,j) 的路径数，转移是 dp[i][j] = dp[i-1][j] + dp[i][j-1]”。这种标签写多了之后，新题出现在你面前时，你能更快地把题目里的场景映射到已知的抽象模式上。模式识别能力，才是从刷题到解题的分水岭。

2. 选对题源和目标难度，比每天多刷两道更重要

很多人的 OJ 练习从一开始就毁在选题上。要么是选的题源跟自己的目标完全脱节，要么是难度梯度安排得毫无章法，导致每天都是在舒适区里重复劳动，或者直接掉进焦虑区里被题解喂饭。

2.1 不同 OJ 平台的定位差异，决定了你不能只用一个题库

稍微整理一下当前大家用得比较多的平台，会发现它们的题目风格和考察侧重点差别很大：

所以你应该先问自己一个问题：我练 OJ 到底是为什么？如果是为了过华为 OD 机考，那最差的选择是天天去 Codeforces 打 Div.1，因为竞赛题的思维难度远超机考要求，你会一直在挫败感中徘徊。反过来，如果你目标是想在算法竞赛中拿名次，只在校内 OJ 上刷课程题是完全不够的，题目的思维量根本不在一个层次。

我的建议是按照“主线 + 辅助”的模式来选题源。主线题库根据最终目标确定：求职向以 LeetCode + 对应公司的真题 OJ 为主；竞赛向以 Codeforces + AtCoder 为主。辅助题库用来补弱点，比如感觉字符串处理弱，就抽两天专门在牛客或者东华 OJ 上找字符串模拟题打底。主线保证方向不偏，辅助保证短板不被忽视。

2.2 难度配比：8:2 法则和“伸手够得着”区间

很多人的刷题列表里只有 Easy 和 Hard，这是一个很典型的误区。Easy 刷多了，思维一直在舒适区里滑行，Hard 题死磕两小时不仅浪费时间，还会严重打击继续刷下去的信心。

我自己一直用的是“8:2 法则”：80% 的精力放在比自己当前水平略高一个档次的题目上，另外 20% 用来搞定那些一眼能看穿思路的简单题或者挑战一下极限难题。所谓“略高一个档次”，就是指那种你读题之后觉得有思路，但具体实现时又会卡壳、需要查一点资料或者试几种边界条件才能写对的题目。这类题带来的进步最大，因为它逼着你把“模糊思路”转化成“精确代码”，这个过程才是真正提升编码能力的过程。

难度配比和数量是两个维度。高质量的 OJ 练习，一天如果能真正吃透两道“略高一档”的题，就已经非常饱和了。我宁可你一周只 AC 十道题，但每道题都独立推导、自己调试、写复盘笔记，也不建议你一天水五十道简单题，刷出漂亮的提交日历然后脑子空空上考场。

3. 一道题从读题到 AC 的标准流程拆解

刷题效率低的人，有一个共同特征：读题不完整就开始想解法，样例一过就急着提交，WA 了才回来看题目，发现漏了关键约束。这套流程极度浪费时间，还会让你养成一个特别坏的习惯——不信任自己对题意的理解。

一道题从出现在你面前到最终 AC，应该有一整套稳定的处理节奏。下面这套流程是我自己固定下来并验证过很多次的，不同基础的人都可以直接拿来用。

3.1 第一步：把题目翻译成自己的语言

拿到一道题，第一件事不是想算法，而是先把题目里的场景、输入输出约束、边界条件，用最直白的话写下来。比如题目说“给定一个数组，找到两个数使得它们的和等于目标值”，你应该在草稿纸上写的是：“输入：一个整数数组 nums 和一个整数 target；输出：两个下标；条件：有且仅有一个解，不需要考虑重复元素”。

这一步的核心作用是把题面里的包装剥离掉，提取出问题的数学本质。很多题目卡人不是卡在算法上，而是卡在对约束条件的忽略上。比如数组长度是 10^5 还是 10^3，直接决定了 O(n^2) 是否能过，而这一点常常藏在题目描述最不起眼的地方。你养成“先翻译条件，再设计方案”的习惯之后，会明显减少因为没看清数据范围导致的设计错误。

具体操作时，我会用两三分钟把下面几项写在纸上，不写清楚绝不动代码：

• 输入的数据结构和规模（是否有序、是否有重复、长度量级）
• 输出要求（下标、个数、路径本身还是路径长度）
• 特殊约束（空输入是否可能出现、元素是否可以重复使用、是否要求相对顺序保持不变）

3.2 第二步：先暴力，后优化，不是浪费时间而是锚定正确性

接了这么多年的题，我最大的感悟之一就是：不要跳过暴力解。很多人觉得比赛或者笔试时直接写最优解才是王道，但那是衡量最终结果的标准。对于练习阶段，暴力解有两个不可替代的价值——第一，它逼着你确认自己完全理解了题目，能写对暴力解说明基本逻辑是通的；第二，它是你后续优化的正确性参照物。

举个例子，很多在华为 OJ 上考过的人都有共识，那种大段文字描述、场景复杂的模拟题，最容易出现“算法思路正确但题意理解偏了”导致满盘皆输的情况。如果你先写出一个能过小数据样例的暴力版本，再用一个数据生成器把暴力结果和优化结果做对拍，就基本杜绝了“对但不知道哪里对”的风险。

对于时间有限的笔试场景，我甚至建议把“暴力 + 优化”的思维固化成一种肌肉记忆：一个题读完后，先在脑子里问自己“如果不管时间复杂度，最简单直接的方法会怎么写？”把这个答案想清楚之后，再去想怎么优化时间和空间。这样做的好处是你永远有一个“保底思路”，不至于在考场上卡住最优解之后直接交白卷。

3.3 第三步：写代码前先明确复杂度目标，并且把它写在注释里

这是我非常推荐的一个习惯。在你开始敲代码之前，先在代码顶部写两行注释：

python复制# 思路：排序 + 双指针，先排序再左右夹逼
# 时间复杂度：O(n log n)，空间复杂度：O(1)（原地排序时）

不要小看这两行注释。它强迫你在动手之前想清楚自己的算法最终要达到什么复杂度标准，而这个标准是由题目数据范围倒推出来的：

• n <= 10^5，O(n^2) 大概率超时，至少要 O(n log n)
• n <= 10^3，O(n^2) 通常可接受，优先保证实现简单
• 涉及取模、溢出，提前明确用 int 还是 long long，避免中间结果爆炸

写完注释再写函数体，你会发现思路清晰很多，代码也自然更有条理。这不仅是刷题习惯，也是工程习惯——真正的项目里，可读性和自解释性比炫技重要得多。

3.4 第四步：AC 之后的复盘，才是一道题的真正开始

很多人 AC 之后直接下一题，这是最可惜的。我理解的 AC 分两个层次：第一次提交就绿，和“再遇到变形题也能 AC”。后者靠的正是 AC 之后的复盘。

复盘我做三件事：

第一，对照题解区的优秀方案，看自己的解法能不能进一步优化。比如自己写的 DP 是二维数组，别人用滚动数组优化到了一维，那多花十分钟把这层优化看懂并自己重写一遍，状态压缩这种技巧就内化了。第二，主动给自己出变式题。同样一道题，如果数组里的元素允许重复，代码怎么改？如果要求输出所有组合而不是只判断是否存在，回溯框架怎么调整？这种“一题多改”的训练比单纯做五道相似题更高效。第三，把这道题的模式标签写进自己的笔记系统，不追求写得长，追求“下次看到类似题，能想起这篇笔记”。

4. 卡在中间最难受：调试排查的系统化思路

O J 练习中最折磨人的阶段，不是完全没思路，而是思路看着挺对，代码写完却不 AC。面对 Wrong Answer、Time Limit Exceeded、Runtime Error 这类反馈，很多人靠乱试，改一版交一版，碰运气成分极高。这一节我把常见的几种卡壳点拆开来讲，给出系统化的排查链路。

4.1 TLE（超时）的排查链路：不是代码不够快，是算法复杂度就已经不对

遇到 TLE，很多人的第一反应是“是不是我常数太大了”，然后开始搞一些局部优化，比如换语言、加快读、开 O2 优化。但实际上，绝大多数 TLE 的根源不是常数，而是算法复杂度在给定的数据范围下根本无法通过。

以 n = 10^5 为例，如果你的核心逻辑是一个双层循环，那整体就是 10^10 次操作量级，再怎么优化常数，也不可能在 1 秒或 2 秒的时限内跑完。这个时候最该做的不是微调，而是回到复杂度目标，重新审视算法设计。

我的排查 TLE 的顺序是：

1. 先用自己的复杂度分析估算出核心代码的总操作量，跟时限 1 秒约 10^8 次操作的经验值做对比。
2. 如果操作量远超 10^8，不要犹豫，直接重设计算法，而不是继续优化局部代码。
3. 如果操作量在合理范围内，才考虑常数优化，比如把递归改成迭代、用数组代替哈希表、避免重复计算等。

还有一种隐蔽的 TLE 来源是死循环。比如二分查找的边界更新写错，导致 left 和 right 永远不会重合，代码会一直空转直到超时。遇到这种 TLE，记得先确认程序是不是真的能跑完——在本地用一个较小但符合题目形状的数据试跑一下，如果小数据都要很久才能出结果，那就别先怀疑时限了，先查逻辑问题。

4.2 RE（运行时错误）和隐蔽边界条件：越界、栈溢出、空指针

Runtime Error 比 WA 要友好，因为它至少说明了你的代码在执行过程中崩了。常见的几种 RE 原因和排查方向如下：

text复制- 数组越界：访问了下标 -1 或 n，典型场景是循环中 i+1 在最后一个元素时还继续访问
- 栈溢出：递归深度过大，例如 DFS 在一条链上的递归深度达到 10^5 以上
- 空指针/引用空容器：调用 front() 或 top() 时容器是空的，典型场景是优先队列或栈没有判空
- 除零错误：模运算中取余数为 0，或除法运算中除数为 0

排查 RE 时，最有效的方法是二分注释 + 打印定位。先把一半代码注释掉，看能否复现崩溃；如果能，说明问题在被注释掉的这段；如果不能，说明问题在被注释掉的这段代码之外。然后在程序崩溃的位置前打印关键变量的值，看到底是哪个条件触发了异常。这种定位方式比瞪眼读代码高效得多。

一个特别容易踩的坑是数据范围导致的下标问题。很多 OJ 题目的数组下标从 1 开始，方便计算前缀和或树状数组，但你不小心写了个从 0 开始的循环，调了半天不知道错哪。每次写代码前先确认下标起点，可以减少很多这类低级事故。

4.3 WA（答案错误）的系统排查：从造数据到对拍

WA 是最常见也最让人头疼的反馈，因为 OJ 只告诉你答案错了，却不告诉你错在哪。排查 WA 我有一套固定动作：

第一步，回到题面，重新审视题意和数据范围。这一步非常重要，因为很多 WA 不是程序逻辑错误，而是你从第一步就理解错题了。比如题目要求输出方案数，你以为是输出方案本身；题目说字典序最小，你只顾着找任意解。

第二步，人工构造边界数据去测试自己的代码。常用的边界数据包括：

• 数组长度是 1 或 2 的极端小数据
• 所有元素都相等
• 数据已经有序（递增或递减）
• 数据包含最大值、最小值、负数、0
• 目标答案不存在的情况（如果题目允许不存在的话）

第三步，如果自己构造数据测不出问题，就用暴力解做对拍。写一个保证正确但复杂度高的暴力版，再写一个小数据生成器，把两个程序的输出不断对比，一旦发现不一致，立刻用那组数据去调试优化版本。对拍是解决“感觉没问题但一直 WA”的最强工具，建议每个人都熟练运用。

python复制# 对拍脚本伪代码（Python 示意）
while True:
    data = generate_small_case()      # 生成小规模随机数据
    out_fast = run_program("optimized.py", data)  # 跑优化版
    out_brute = run_program("brute.py", data)     # 跑暴力版
    if out_fast != out_brute:
        print("找到反例:", data)
        break

这套流程熟练之后，你会发现 WA 的解决时间被大大压缩。它跟经验没关系，纯粹是一种排查习惯——习惯好，什么都不怕。

5. 从“会做题”到“会应用”：OJ 练习如何转化成实战能力

刷 O J 的最终目的，绝对不只是在 OJ 平台上把题目刷绿。对于大部分人来说，这个练习最终要兑换成两类东西：一类是笔试面试中的通过率，另一类是解决真实工程问题时的算法思维。这两者之间有交集，但并不完全等同。

5.1 面试/机考场景的实战技巧：先保底，再优化

像华为 OD 机考、大厂笔试这类场景，和平时在 OJ 上刷题有一个很大的区别：时间有限、压力大、题目之间有难度梯度。这个时候如果每一道题都死磕最优解，可能前三道题就耗掉大部分时间，最后最值钱的那道题反而没时间写。

我的策略是“分层拿分”。先快速浏览全部题目，把题分成三类：第一类是看一眼就有稳定思路的，马上写，争取一次 AC；第二类是有点想法但不确定最优解的，先写暴力或者部分分版本，保证拿一部分分数；第三类是完全没有头绪的，最后处理。这种策略的本质是在笔试这种“得分最大化”场景里，不追求每题完美，而是追求总分最大化。

另一个不可忽视的实战细节是环境差异。很多 OJ 平台使用的输入输出格式、编译选项、内存限制，跟你本地环境不完全一样。比如牛客和华为 OJ 的输入样例可能包含多组测试数据，你的代码需要用 while 循环读到底——处理不当会导致只通过一组数据就报错。平时练习时可以偶尔在目标平台而不是只在本地 IDE 上做题，提前熟悉实际比赛环境和提交判定的手感。

5.2 工程层面：算法思维是对“复杂度意识”和“边界意识”的训练

一些人觉得工作之后就不用刷题了，这是一个相当片面的判断。虽然日常业务开发里很少会直接让你手写一个红黑树或者线段树，但算法的底层思维——复杂度分析、数据建模、边界条件处理——却是每天都在用的。

举个例子。你在处理一个大数据量的日志分析任务，第一反应是选择遍历还是建索引，本质上就是 O(n) 和 O(log n) 的取舍。你在写一个接口时考虑是否需要对空参数、超长字符串、并发冲突做特殊处理，本质上就是 OJ 题里“边界条件是否考虑周全”的延伸。刷题训练出来的不是某个数据结构的背诵能力，而是面对一个模糊问题，能够快速建模、定位瓶颈、设计方案的能力。

我经常跟朋友说的一句话是：OJ 练习练的不是题，是“把复杂问题拆解成可执行步骤”的底层素养。今天你在 OJ 上把一个状态压缩 DP 调通，明天你可能就能更从容地面对线上一个需要多条件分流的复杂规则引擎。这两件事表面无关，内里的抽象和拆解能力是一致的。

5.3 复盘笔记的积累：建立自己的“解题索引”

最后分享一个长期价值最大的习惯——写复盘笔记，但不是那种长篇大论的感想，而是给自己建立一套类似“索引”的结构。我自己的笔记格式很简单，核心就几个信息点：

• 题目名称和来源平台
• 核心考点（一两句话，落实到具体的数据结构和算法模式）
• 解法摘要（用自己的语言描述，不用官方题解的原话）
• 易错点记录（比如“前缀和数组长度要开 n+1”“排序时比较器不要返回布尔值要返回整数”）
• 变形方向（哪些条件变了会变成另一类题）

随着笔记积累到一两百条之后，它的价值会超过任何一本市面上的题典。因为你复习时看到的不是别人总结的抽象套路，而是自己曾经真实踩过的坑和灵光一现的推导路径。每次笔试前，我基本上只用翻自己的笔记索引，就能把常见的几大类题型和配套的易错点在脑子里串一遍，这种复习效率比重新刷题高得多。

还有一个很个人的建议：不要在笔记里用“简单”“不会”“好难”这类纯情绪词汇做标签，因为情绪词汇在复习时没有任何检索价值。有信息量的标签应该是“背包变形”“二叉树遍历与序列还原”“滑动窗口+单调队列”这种短期内就能定位到某个具体知识点的短语。

6. 长期练习的节奏管理与心态维护

聊完具体方法，最后说一说更宏观的层面——OJ 练习是一个长期过程，怎么安排节奏，才能既不三天打鱼两天晒网，也不因一时瓶颈而彻底放弃。

6.1 设定“可量化”的阶段性目标，而不是“我要变强”这种空话

目标不能太低，也不能太抽象。“每天做一道题”听起来不错，但如果某天只是一道非常简单的 Easy 题，这个目标的训练效果就接近于零。建议用周或者双周为周期来规划：

text复制示例第一周目标：
- 周二前：独立 AC 二叉树的层序遍历及相关变形题 3 道
- 周四前：写一篇“二叉树问题通用模板”的笔记
- 周五：在 Codeforces 上随机挑一道 1400~1600 分的题，限时 1 小时尝试
- 周末：整理本周错题，重新手写一遍 WA 过两次以上的题

这样的目标有三个特点：可执行、可衡量、有挑战但可通过努力达成。周期性复盘时也能清晰看到自己在哪个环节花了最多时间、有哪些薄弱点没解决。比起“本周多刷点 DP 题”，这种目标让人更有掌控感。

6.2 瓶颈期的正确打开方式：不是猛冲，而是降维和补漏

练题练到一定阶段，一定会遇到“平台期”，明明感觉最近状态不错，但新题就是 AC 不了。这时候多数人的直觉反应是加大力度，每天硬扛更多难题，试图用数量砸过去。但我个人的经验是，瓶颈期最好的策略是降维——回退半档，找一些比自己当前水平略低，但涉及同一核心知识点的题目重新做一遍。

为什么要降维？因为瓶颈的本质通常是某些底层的基础不牢固。比如你 DP 题一直做不顺，可能不是状态设计能力弱，而是对于“递归到递推的转换”或者“记忆化搜索的返回值定义”理解不透。这时候去啃高难度区间 DP 是没用的，先把基础版的线性 DP 做到看到题目条件就能条件反射地写出转移方程，瓶颈往往会自然缓解。

这个阶段还有一件事很重要：降低单次练习的心理预期，不要把“今天必须 AC 一道 Hard”当成指标。人的状态本来就有波动，允许自己有“低速日”反而能让长期坚持变得容易。真正的 OJ 高手不是从不失败的人，而是跌倒了知道怎么重新爬起来、并且能从失败里提取信息的人。

以上这些，都是我花了很长时间、绕了很多弯路才沉淀下来的方法。回头看，真正让我从“OI 选手的思维残废状态”转型为“稳定应对笔试和工程场景”的，不是某一次突击训练，而是把上面这些原则——选题、流程、调试、复盘、节奏——变成一套可持续的日常系统。希望这篇关于 OJ 题目练习的复盘，能让你少走一些我走过的弯路。