如果你在一家OJ平台上刷题从1刷到10只算热身真正让人停下来产生“卧槽原来是这样”的瞬间往往发生在100题之后。我最近刷的一批题里恰好卡在第133到135题这个区间花了一个多星期才彻底理顺。回头复盘的时候发现这三道题其实代表了OJ刷题路上最常见的三类卡点也逼着我把在线判题系统背后的判定逻辑、复杂度分析、输入输出习惯重新捋了一遍。这篇就把这段经历拆开讲清楚顺便聊聊华为OJ这类企业自研判题平台和传统ACM平台之间的差异以及一套我自己用着有效的刷题复盘框架。不管你是刚入坑的萌新还是已经刷了两三百题的进阶选手希望这篇能给你一点可复现的思路而不是又一份“刷题鸡汤”。1. 一套判题系统到底在卡你什么——OJ背后的运行机制先说点基础但特别容易被忽略的东西。很多人刷题刷到后面只看AC和WA两个结果从来不关心判题系统是怎么得出这个结论的。实际上一次提交从你点击“提交”到界面上出现结果中间经历了编译、运行、比对三个环节任何一环出问题都会变成红色。1.1 判定结果只有AC和WA远比你想的更严格OJ的判定结果远不止Accepted和Wrong Answer。常见的还有编译错误、运行错误、超时、超内存、输出格式错误、部分正确等等。我见过不少初学者看到“Compile Error”就懵了——本地VS里跑得好好的怎么一上来就是编译错误原因通常是两个一是OJ的编译器和你本地的编译器不是同一个比如本地用的MSVCOJ用的是GCC某些写法在MSVC里能过换GCC就报错二是很多人图省事用了非标准头文件或者依赖了本地环境的隐式行为这在OJ那种干净环境里非常致命。我踩过的一个典型坑是函数名和标准库撞了导致编译期二义性在本地因为预编译头遮挡了错误一上OJ立刻暴露。1.2 时间复杂度和空间复杂度题目存在上限的数学表达判题系统对程序的约束只有两个维度时间和内存。时间限制常见的是1秒或2秒内存一般是256MB或512MB。换算成代码层面的意思就是如果你写了一个三重循环处理一万规模的数据1秒内大概率会超时如果你的局部数组开得太大就会把运行栈挤爆直接返回运行错误。我习惯在动手写代码之前先做一次粗略的复杂度估算。假设时间限制1秒C大概能跑上亿次简单运算但如果你用了STL的map或unordered_map这个数字会缩水很多。复杂度的意义不是让你背公式而是让你在写之前预判“这条路走不走得通”避免写完一提交就超时白白浪费一次提交机会。1.3 什么是隐藏测试用例为什么没有反馈信息这是新手的另一个误区以为OJ上的题目只有题目描述里那两三个示例输入输出。实际上判题系统里放着大量隐藏测试点覆盖边界、极端规模、特殊字符、非法输入等场景。你的代码必须对所有这些测试点都输出正确结果才能拿到AC。所以调试的时候仅仅对着示例数据跑一遍是远远不够的。我自己的做法是在提交之前手写几个边界用例自测空输入、单元素、最大规模、重复元素、负数、字符串含空格和换行。这些用例往往比题目示例更能暴露问题。而且OJ一般不返回具体隐藏用例的输入输出你能看到的只有一个结果这意味着你必须自己承担测试工作这也是刷OJ和写业务代码最大的不同之一。2. 从133到135三段典型的刷题卡点对应三类几乎必考的算法我刷到第133题的时候正好处于一个比较尴尬的阶段简单题已经刷腻了中等题开始上难度每道题都要花一两个小时。这个区间的三道题恰好让我把三类最常考的核心算法重新审视了一遍。2.1 第133题字符串类问题精读题意的坑这道题给我的第一印象是“挺简单”读完题我立刻想到可以用暴力匹配实现写了不到二十行代码提交WA。再读一遍题才发现我对题意的理解漏掉了一个关键限制——字符串长度上限是10万级别暴力匹配的时间复杂度是平方级必然超时。字符串类题目坑最多的地方往往不是算法本身而是对处理范围的误解。很多人看到“字符串”就下意识地用两层循环挨个比较完全没算过10万乘10万是什么概念。正确思路通常是转成哈希、前缀和、滑动窗口或者KMP这类线性算法。这里我想多说一句刷字符串题的时候一定要把读题当成一个严谨工程来做圈出所有数字限制、字符集范围、大小写是否敏感、是否允许重复、是否要求连续。这些细节直接决定算法选型和代码结构漏掉任何一个后面都要退货重写。2.2 第134题数据结构类问题选对容器事半功倍第134题我花的时间最长不是因为它难而是因为我一开始选错了数据结构。当时我拿到题目之后第一反应是用数组强撸结果需要对中间元素频繁插入删除数组操作是O(n)的整体复杂度根本扛不住。后来才反应过来这类场景应该用链表。这道题让我悟了一个道理数据结构不是学了就完了而是要在看到题目特征的时候瞬间匹配到对应的容器。频繁查找用哈希表保证有序用平衡树先进后出用栈先进先出用队列中间插删用链表。这不是什么高深理论就是一个熟练度问题。练习方法也很朴素——同一个题分别用两三种数据结构各实现一遍对比不同思路的代码长度和运行时间做一次“一题多解”的刻意训练。2.3 第135题动态规划类问题别盯着状态方程死磕第三道题的典型特征是“看起来没有思路其实只是没找到重叠子问题”。我拿到之后想了一个小时一直往贪心方向上使劲卡了很久。后来换了个角度把它拆成子问题去推才发现这就是一道非常经典的动态规划。动态规划题我现在的处理顺序是固定的先定义状态再明确状态转移然后确定初始化和边界。不急着一步到位推公式而是先从最朴素的暴力递归开始画出递归树找到重复计算的节点再升级成记忆化搜索最后改写成递推。这个递进过程比直接看答案背公式有用得多因为公式是结果递归树才是原因。第135题让我印象最深的点在于很多人包括当时的我一上来就拿着状态转移方程硬套套不上就觉得“这题我不会”其实只要愿意从递归暴力开始推一遍很多DP题根本不需要背。3. 华为OJ的判题风格与刷题策略——以面试导向倒推训练重点聊完通用机制再说说华为OJ这种企业自研判题平台。现在不少人在牛客或者华为自己的OJ上刷机考题准备笔试和面试。这和早年打ACM用的POJ、HDU、Codeforces其实有很大区别策略上必须调整。3.1 企业自研OJ与ACM-ICPC判题的差异传统ACM竞赛平台的题目追求极致的算法难度和思维巧劲有些题甚至没有标准解法考的就是临场想出合适状态的能力。而企业自研OJ尤其是面试场景下的在线考试更偏向于“工程化”和“实用化”。题目整体难度会低一档但要求你写出的代码能真正处理各种现实输入边界情况一个都不能漏。华为OJ的机试和OD机考在业界比较有代表性它通常不要求吃透复杂高级数据结构更看重基础编码能力、逻辑清晰度、代码规范程度。这意味着你花大量时间钻研后缀自动机、网络流这种冷门算法不如把基础排序、字符串处理、哈希表、简单的DP练扎实性价比反而更高。3.2 以华为机试为代表的题型分布根据我自己刷题的经验和周围人的反馈华为机试的题型分布大致有规律字符串处理几乎必考数组和排序出现频率高简单数据结构栈、队列、哈希是家常便饭动态规划偶有出现但难度通常不高。真正卡人的点往往是输入输出的格式处理和边界条件判断比如多组输入要不要持续读到EOF每行数据的个数是否固定输出末尾是否允许多余空格。我实测下来的结论是在华为OJ上想拿高分不用追求偏题怪题而是要把“常见题的常见变体”都过一遍。同一个题目样例过了不算过你要自己构造极端输入去测直到在各种输入下都稳如老狗。3.3 冲刺阶段的时间分配如果你是为华为OJ这类企业平台做准备我建议刷题策略反过来——先刷专题再刷套题。先用两周左右把基础数据结构、字符串、排序、二分、贪心、DP这几个大类的代表性题目各刷20道左右每道题都要做一题多解和复杂度分析然后进入模拟考试阶段每天一套题掐着时间做模拟真实机试的紧张感。很多人在机考翻车不是因为题目不会做而是因为前面某道题卡太久导致后面简单题都没时间写。所以我自己的原则是机试时先花五分钟把所有题看一遍先做会做的再做有思路的最后才回头啃硬骨头。这个策略让我在好几次模拟中比按顺序做多拿了不少分。4. 刷题提效的底层框架从“AC了”到“真会了”要补的三个环节我见过太多人刷了五百题还是害怕笔试原因很简单——他们只是“AC了”并没有“真会了”。AC只是结果过程才是关键。我自己总结了一套刷题提效框架核心就是三个环节刻意练习、精读复盘、复杂度分析。4.1 刷题数量与质量的关系有一种观点是“刷够300题自然就懂”我觉得这话对了一半。刷题数量确实有用但前提是刷的过程中真正动了脑子。无脑重复同一难度、同一类型的题目刷一千道也只是在舒适区里打转。我更喜欢采用“T型刷题法”来平衡数量与质量。竖向是深度题每个核心算法挑两三道代表题反复做直到你能不看题解从头写到底横向是广度题尽量覆盖不同类型的题目保证自己见识过各种出题角度。这样刷下来我一年只刷了两百多道但面对没见过的题型的抗压能力比很多刷了五百道的人强得多因为训练的重点是“迁移能力”而不是“记忆答案”。4.2 一题多解与复杂度下界每道题AC之后我会强迫自己再想一个不同的解法。比如一道排序题我会先写个快速排序然后想想堆排序怎么写再想想如果数据范围变化排序算法是不是该换。这个过程不只是为了装酷而是因为面试里很爱问“这道题还有没有更好的解法”如果你在一开始刷题时就养成了这个习惯面试时你就不会卡壳。这里让我再补充一个概念复杂度下界。每个问题都有一个理论上最低的复杂度底线比如基于比较的排序最少也要O(n log n)。了解下界不是为了写论文而是为了在面试和做题的时候对“为什么不能用更好的方法”有一个清晰的说法。很多HR轮和交叉面会问类似的问题能答上来的人非常少。4.3 一份可复用的刷题复盘模板复盘比刷题本身更重要。我每次做错一道题都会在题解后写一段简短记录包含四个固定字段错因分析、算法标签、突破点、以及“如果下次遇到类似题我的第一步应该是什么”。这么记录的好处是下一次碰到同类题目你不再是从零思考而是直接调用之前的经验。这种“元认知”层面的积累才是题量转化为能力的真正途径。如果你觉得记录很麻烦退一步讲至少记录错因这个习惯会在期末复习或面试前救你一命。5. 那些在OJ上踩过才会懂的坑最后聊点实操层面的坑这些坑几乎人人都踩过但网上系统总结的很少。我把它们按产生原因分成三类每一类背后都对应着一个经常被忽略的细节。5.1 边界条件比算法本身更决定AC我审过很多朋友写的代码发现一个普遍现象算法思路没问题却总是差一两个测试点过不去。排除掉隐藏输入之外最常见的原因是边界条件写死了。举个例子如果题目说数组长度是n你在代码里写了if(i n - 1)作为输出格式判断就要想一想n等于0的时候会不会越界访问如果用到动态规划下标从1开始方便递推那下标0的位置就必须初始化好不能让它变成未定义的脏数据。边界问题是那种“本地永远测不出来、一提交就碎”的典型。5.2 输入输出格式的隐性要求C里cin和scanf的混用是个老话题。如果你的代码里同时用了cin和scanf甚至有的一行用cin读下一行用scanf读在部分OJ上会出现输入流错位的问题。更稳妥的做法是锁死一种风格我一般全用cin并且关掉同步ios_base::sync_with_stdio(false)。另外题目要求每行输出后换行如果你用printf注意\n不能少如果你需要按空格分隔输出最后一个元素之后到底等不等价于允许尾随空格那道题说了算。还有个隐藏的点有的题目是多组输入标准是读到EOF为止。这种题最容易栽在“只处理了一组数据就return”上。一定要学会用while(cin n)包住核心逻辑养成习惯。5.3 本地能跑、OJ上全错的一类原因这类问题排查起来最痛苦因为你无法复现。最常见的几个原因你用了未初始化的变量本地编译器恰好给了个0OJ的编译器给的是垃圾值你开了一个超大数组在函数内部本地栈空间大侥幸没炸OJ上栈空间小直接爆运行错误你用了位运算处理负数但到底往左移还是往右移C标准没完全定义不同编译器行为不同。碰到这种“玄学”问题我的排查顺序是先全局搜索所有局部大数组把它们统统挪到外面去再检查所有变量声明处是否都赋了初值最后把涉及位移和溢出的代码重写一遍尽量用更直观的方式表达。这套流程能解决九成以上的“本地能跑提交就挂”。就拿数组来说很多新手不理解为什么OJ上大数组要放全局。我把这当成一个习惯性动作不管你要开多大的数组直接放到所有函数外面。这不是什么高深优化就是为了防止栈溢出把内存分配放到数据段而已。6. 这台OJ在线判题系统的背后正好契合了这个训练逻辑把镜头拉远一点说个题外话。现在GitHub上有很多开源的OJ在线判题系统项目像编程导航的鱼皮项目里就有一套很经典的Java实现从题目管理、提交判题到结果展示整套流程跟真实OJ完全一样。我自己跑通过一个简化版用了Docker隔离用户代码配合沙箱限制时间和内存再加一层测试用例比对。当你亲手实现过一次判题系统之后你再回去刷题看待AC和WA的眼光会完全不同——你不再是一个黑盒用户而是明白背后所有环节的裁判。说白了判题系统自己能跑核心就是三件事隔离不安全代码、控制资源上限、比对输出结果。你自己实现一遍才会真正明白为什么OJ会判你超时为什么某些写法能过而某些写法必挂。这也是我强烈建议有一定基础的人去折腾一下OJ在线判题系统项目的原因。它把操作系统、网络、编程语言、数据结构、设计模式全串在了一起是个非常完整的综合实践项目。而且你刷题时学的那些复杂度分析在写判题系统的人眼里就是用来封顶的东西——他们精心卡住时间和内存上限目的就是逼你写出高效的代码。说回刷题本身。第133到135这道坎现在回头看真正帮助我的不是多背了几道题解而是这三个习惯动手前先做复杂度估算提交前先过边界自测AC之后再记录错因和突破点。如果你正刷在一个类似的瓶颈期不妨按这个顺序调整一下自己的节奏哪怕只改前两条你下一次提交的通过率也会明显不一样。