考研复试机试C/C++回顾
每年复试季，总有学弟学妹问我机试到底怎么准备、难度如何、该刷哪些题。说实话，机试这东西不像笔试那样背一背就能过，它考察的完全是另一套能力——短时间内的代码实现、调试、还有临场心理素质。我自己当年备考的时候踩了不少坑，也总结了一些真正有用的经验，这篇就完整回顾一下。如果你正在准备复试机试，或者对C/C++机试心里没底，这篇文章应该能帮你在有限时间内走最稳的路径。我会从整体策略、环境准备、核心考点、实操技巧到常见问题，全部展开讲清楚。
1. 项目概述与思路拆解
1.1 考研机试到底考的是什么
很多同学把机试当成笔试的延伸，用复习笔试的思路去刷概念题、背诵知识点，这是最大的误区。机试本质上是在模拟“给你一个明确任务、限制时间、要求你写出可运行代码”的工程场景，它考察的是你能否把算法想法快速转化为实际代码，并且能够正确运行、结果无误。
说得直白一点，笔试考察“你是不是知道这个知识点”，机试考察“你能不能把事情做出来”。这也是为什么很多笔试高分的同学在机试翻车——他们熟悉复杂度分析、能默写算法流程，但到了真机环境里，连scanf和cin的混用导致输入异常的问题都排查半天。
不同学校的机试形式不完全一样，但主流无非几种：单题限时（一般是60到90分钟完成1到2道题）、多题限时（2小时内完成4到6道题）、OJ平台评测（全程黑盒跑数据，不看你代码风格，只看结果）。最要命的其实是OJ平台评测这种，因为这意味着你的代码必须一次通过所有隐藏测试用例，任何一个边界条件考虑不周，都会让你这道题直接零分。
所以我当时的备考策略就是：从一开始就当自己在OJ平台上做题，严格按格式、严格想边界、严格测极端数据。平时养成习惯，考场上才不会慌。
1.2 为什么C/C++是机试的主力语言
这其实是个很现实的问题。虽然现在Python也很流行，算法题写起来还快，但在考研机试场景下，C/C++依然是绝对主力。原因有几点：
第一，几乎所有高校的机试环境都预装C/C++的编译器，无论是Visual Studio还是Dev-C++还是Code::Blocks，都原生支持C和C++，不需要额外配置解释器。而Python环境在某些弱网或不提供外网的考场里，反而不一定预装，或者版本很老，容易出幺蛾子。
第二，C++的STL（标准模板库）简直是机试神器。vector、stack、queue、set、map、sort、next_permutation、priority_queue这些容器和算法，能省掉你大量造轮子的时间。两道同样难度的题，用C++写STL可能30分钟搞定，手写数据结构的C版本可能要50分钟，差距是非常明显的。
第三，机试判题对运行时间有硬性要求。C/C++在OJ上的运行速度比Python快很多，这意味着同样是O(n log n)的排序算法，C++能过，Python可能就被卡超时了。在复试机试这种短时间内要出结果的场合，C/C++能提供更大的容错空间。
当然，我不是说Python完全不行——如果你的目标院校明确说了支持Python，或者你自己就是Python特别熟练、C/C++薄弱，那也可以考虑。但一般来说，除非有明确信息，否则老老实实用C/C++是风险最低的选择。
1.3 备考时间线是怎么规划的
机试备考最怕的就是“不知道考什么、不知道练什么、不知道该练多久”。我根据自己的经验，给一个比较通用的时间线参考：
- 复试前8到12周：主攻基础功底。重点是C/C++语法死角、STL常用容器、经典算法模板（排序、二分、双指针、栈和队列、二叉树遍历等）。这个阶段不用限时，先把每道题吃透。
- 复试前4到8周：主攻OJ刷题。每天保持2到3道题的节奏，严格按照OJ的输入输出格式。这个阶段要开始限时训练，单题控制在40分钟以内。
- 复试前2到4周：主攻模拟套题。找目标院校的历年机试题，或者类似的模拟套题，按考试的真实时长连续做题，培养连续编程的耐力和心态。
- 复试前最后1周：主攻查漏补缺。把之前的错题、容易犯的错误、常用模板的代码全部过一遍。不要再死磕难题，保持手感即可。
这套时间线不一定适合所有人，但“基础阶段—刷题阶段—模拟阶段—巩固阶段”这个方向是对的。最忌讳的是从第一天就盲目刷难题，导致基础不牢，后期越刷越虚。
2. 环境准备与关键工具选型
2.1 机试环境早知道，不要最后一天才去适应
机试失败的最冤情况，就是平时用得顺手的IDE到考场上被限制，或者根本没预装。所以信息收集阶段有一个必须做的事：想尽办法弄清楚目标院校的机试环境。
最常见的几类环境我列一下：
- Dev-C++ 5.11：很多高校的机房老古董，界面朴素，但稳定、启动快，对标准C/C++支持没问题。如果你平时用VS Code，提前熟悉一下Dev-C++的调试功能会很有帮助，不然考场上按F9没反应都不知道去哪设置编译选项。
- Visual Studio：部分学校用，功能强大，但缺点是对标准兼容性细节要求高，且启动重。要特别注意：VS默认会启用“安全开发生命周期”检查，scanf、strcpy这种老牌函数直接报C4996错误，需要加预处理指令或者改用scanf_s。这就有个坑——平时在VS上写scanf_s写得顺手，到了OJ平台编译器不认这个函数，直接编译错误。
- Code::Blocks：轻量、跨平台，对标准支持好，部分Linux机房和Windows机房都有。
- 纯Linux环境 + vim/gcc：极少数学校会这么干。如果你目标院校是这个路子，提前练命令行gcc编译和gdb基础调试，不然到考场连怎么编译都不知道。
我备考时拿到的最关键信息就是目标院校用Dev-C++ 5.11 + C++11标准，于是前期直接用Dev-C++训练，到后期基本不看其他IDE。提前匹配环境省了很多无谓的适应成本。
2.2 编译器和标准的选择
C和C++虽然经常放在一起说，但考试的时候你最好明确自己写的是哪个。选C就按C99/C11的标准写，选C++就按C++11或C++14的标准写，最怕的就是混合写，代码看着能过，但某些老编译器会有诡异行为。
给大家几个实战建议：
其一，如果用C++，优先使用C++11或更高标准，因为C++11带来的auto、unordered_map、emplace_back这些特性确实能节省时间。但注意：不是所有学校的环境都支持C++14或C++17，保守起见C++11是最大公约数。
其二，如果用C，就尽量避免C99以后才有的特性。比如在代码块中间声明变量，有的学校编译器用C89模式可能直接报错。最稳妥的方式是全部在函数开头声明变量，这是C89风格，在任何编译器下都能编译通过。
其三，一定要知道自己用的编译器默认的编译选项是什么。Dev-C++里默认可能不是-std=c++11，你要在【工具—编译器选项】里手动加上。我在模拟测试的时候就吃过亏，写了一个C++11特性代码，本地没问题，换了台测试机器直接编译失败，就是这个原因。
2.3 刷题平台怎么选
绝大多数机试题目，本质上是标准OJ题。所以你平时训练的刷题平台越接近考试环境越好。比较推荐的平台有三类：
第一类是目标院校自有的OJ平台，一般在校内可以访问，上面有历年的机试真题，这是最最最重要的复习资料。如果搞不到历年题，也尽量找学长学姐打听题目的风格、难度、题型分布。我当时就是通过学长给的回忆版题目，大概知道了出题人偏好（爱出图论和模拟题），复习就有了重点。
第二类是主流刷题网站，比如各类OJ上的入门到进阶题库，按难度梯度刷。不过我建议不要随机乱刷，最好按考点分类刷，每个考点集中练，这样能够在有限时间内快速覆盖多个高频题型。
第三类是带比赛/模拟功能的平台，这类网站有些会有周赛、月赛，限时排名，跟考试的紧张感比较接近。我在临考前几周参加了若干场模拟赛，虽然排名一般，但限时做题的感觉真的和平时散刷完全不一样，对心态帮助很大。
3. 核心考点与高频题型分析
3.1 考察频率最高的几类题目
根据我收集的多所高校机试信息和自己的考试经验，机试题目无论怎么变化，核心考点基本集中在以下几个方面。
第一大类是模拟题。给你一个实际问题场景，让你照着规则一步步做。这类题考察代码组织能力和细节处理能力，往往不涉及高深算法，但对逻辑严谨性要求极高。比如“给定一个日期，求它是星期几”“模拟一个银行排队系统”“实现一个简易计算器”。很多同学在这种题目上翻车，不是因为不会做，而是因为“差不多就行了”的代码经不起推敲。
第二大类是经典数据结构和算法题。栈和队列的运用、链表的操作、二叉树的前中后序遍历、图的深度优先和广度优先搜索、最短路径（Dijkstra和Floyd）、最小生成树（Prim和Kruskal）、排序算法、二分查找、动态规划入门问题。这里想特别强调：动态规划是很多学校的高频压轴题。从背包问题到最长递增子序列，再到区间DP，基本是必考重点。
第三大类是字符串处理题。字符串逆转、子串查找、模式匹配、大数运算（高精度加减乘除）。这种题目看着简单，实际写起来很考验基本功，特别是C语言风格的字符数组处理，很多人C++的string用得飞起，但一遇到字符数组就gg，其实两种写法都要熟练。
第四大类是数学题。质数判断、最大公约数和最小公倍数、快速幂、大数取模、进制转换、排列组合。这些题数量不算多，但一旦出现，往往是拉分题，因为代码量不大，但思路要清晰。
第五类是文件读写类型。某些学校会直接在题目里要求从文件读入、写出结果，而不是从标准输入读。这个细节如果你没注意，代码写出来可能本地运行完全正常，但在OJ上就是零分。所以备考时一定要养成看题目输入输出说明的习惯。
3.2 每个高频考点的应对策略
模拟题的核心策略只有一个：仔细读题，提取所有规则，用数据结构去映射现实场景。比如银行排队问题看上去是个复杂场景，但抽象出来就是队列的操作。这种题只要理清规则，代码并不难写。建议是先在草稿纸上画一个流程，再动手写代码，不要边写边想规则，很容易漏。
二叉树和图的遍历是必拿分题。DFS和BFS两种写法要达到“肌肉记忆级”的程度，不需要思考就能敲出来。特别是DFS，很多题目都是它的变体，比如迷宫问题、岛屿数量问题、N皇后问题，全都万变不离其宗。我自己的训练方法是：把DFS和BFS的模板默写十遍以上，直到在任何条件下都能快速、准确地写出来，这比刷十道新题更管用。
DP题目是区分度最高的一类。掌握DP的关键是三步：第一步定义状态，第二步写状态转移方程，第三步初始化边界条件。很多同学卡在“不知道状态怎么定义”上，我的建议是以背包问题为例反复看状态转移的推导过程——为什么是前i个物品在容量j下的最大价值？把这个理解透了，很多DP题的套路都是一样的。
字符串处理要特别注意空串、空格、大小写、越界问题。C风格字符串的结尾标志是\0，很多错误的本质就是忘记给字符串末尾留位置。比如你要拼接两个字符串，char s[100]，但实际读入的字符串长度可能已经超过99，再加上\0就直接缓冲区溢出。这类“隐蔽Bug”在OJ评测里非常吃亏。
数学题看起来很唬人，但实际上考的都是固定套路。质数判断用试除法到sqrt(n)就够，最大公约数用辗转相除法，快速幂用二进制拆分思想，高精度加法用数组模拟竖式。这些模板我建议全部提前准备好，考场直接用，而不是临时推导。
3.3 拿高分必须养成的习惯：边界条件与极端数据
我见过很多代码，算法思路完全正确，但一提交就是Wrong Answer。最后排查发现，问题全出在边界条件上。这是机试中最普遍、最可惜的丢分点。
边界条件常见的有这么几类：
- 空输入。如果输入行数为0，程序应该怎么处理？很多人的代码会对空输入做非法操作，直接崩溃。
- 最小值和最大值。当n=1，m=1，数组只有一个元素时，代码是否还能正确运行？
- 负数。题目说“整数”，到底包不包括负整数？如果包括，你的排序、求和、动态规划初始化是否考虑了负数的情况？
- 大数溢出。int最大值约21亿，如果你求的是累加和、累乘积，可能早就超了int范围，要用long long，甚至字符串处理。
- 重复元素。排序时相同元素怎么处理？查找时出现多个结果输出哪个？有些题目会明确要求输出最小下标，你没注意就错了。
应对边界条件最好的方法就是：每个题写完之后，设计几组极端输入实际跑一遍。比如一个排序题，试试n=1的输入、全相等元素的输入、已经排好序的输入、完全逆序的输入。这几组数据跑通了，这个题的正确率就比较稳了。
4. 实操过程与核心环节实现
4.1 输入输出那些“坑”，一次统清楚
机试的输入输出格式是很多考生最大的痛。我自己也在这一块严重吃过亏，这里详细讲透。
首先是循环读入的问题。OJ题目常见的输入格式有几种：第一种是固定数量的输入，比如“第一行输入n，接下来n行每行两个整数”，这种直接读n然后循环n次就行。第二种是不告诉你数量，要求一直读到文件尾（EOF），这个时候要用while(cin >> x)或者while(scanf("%d", &x) != EOF)的写法。这两种读入方式差别很大，一旦判断错，很容易陷入死循环或提前退出。
其次是输出格式的严格性。OJ评测机对比输出时，通常忽略行末空格，但对空行和多出的空格很敏感。题目要求“两个数之间用一个空格分隔”，那最后一个数后面就不要再额外地输出空格了。我的习惯是：先输出第一个数，从第二个数开始前面加空格，判断条件用 i > 0 来控制。
再有一个很关键的坑：换行。很多题目会特意说明“每组输出占一行”，或者“每个输出之间用一个空行隔开”。有没有那个多出来的空行，评测结果完全不同。所以每次写完代码，对样例输入多跑几遍，仔细检查组与组之间的空行是否和题目描述一致。
最后，字符串的输入最坑。scanf不能读入带空格的字符串，要用gets或者cin.getline，但gets在C11标准里被移除了，会报警告；cin.getline又容易和cin混用之后出现遗留换行符的问题。我有一个百试不爽的组合方案：C++风格的输入全部用cin处理字符串，需要读整行时用getline(cin, s)。关键是注意：如果你前面用了cin >> n，后面马上用getline(cin, s)，getline会先读到一个空行，因为输入缓冲区里还留着上次输入结束时的换行符。解决办法是在cin >> n之后加一句cin.ignore()，把这个换行符吞掉。
4.2 C和C++混用，如何安全避开雷区
很多学校机试允许C和C++二选一，但也有不少同学为了图方便，两个混着写，这极其容易出问题。最典型的就是cin/cout和scanf/printf混用。在C++里，cin和scanf有各自独立的缓冲区机制，如果你一会儿cin一会儿scanf，输入顺序就可能错乱。正确做法是：
要么全部用C++风格（cin/cout），要么全部用C风格（scanf/printf）。考试时统一一种风格，可以省掉大量无谓的调试时间。
个人建议：如果题目以字符串处理为主，用C++风格，string类和相关的查找、拼接函数会省很多事；如果题目以大量数字读入为主，用C风格，scanf/printf确实效率更高、格式控制更灵活。但要记住，选了就要一用到底。
还有一个常见的踩坑点：C++的bool类型在printf中不能直接输出true/false，要用%d输出1/0。有些人觉得无所谓，但在输出“YES/NO”这类要求时，千万不要自作聪明地用printf("%s", bool变量)，会直接输出空字符串。
我自己的一个习惯是：写C++代码时，主力用cin/cout，但遇到需要控制小数位数时用printf搭配%.2lf，这是C和C++之间为数不多的合理混用，因为cout的格式控制代码有点啰嗦。当然，用cout就更统一的方案是iomanip头文件里的setprecision和fixed，但语法相对复杂一些，容易写错。
4.3 常用算法模板，考前直接背下来
机试时间紧张，现场推导模板非常浪费精力。我建议把以下模板提前整理成自己的代码库，考前默写几遍，保证随手就能完整写出来。
排序模板：可以手写快速排序或归并排序，但更推荐直接调用sort，复杂度和正确性都有保障。注意sort在C++里默认升序，如果要降序，写法是sort(a, a+n, greater<int>())，或者自己写一个比较函数。
二分查找模板：这是最容易写错的重要模板。核心是while (left < right)时mid怎么取、边界怎么移动。我分享一个我用了很久的模板：查找第一个大于等于target的位置，或者查找最后一个小于等于target的位置，这两种变体建议分别整理清楚，考试时直接套。
DFS模板：void dfs(参数) { if (递归出口) { 处理结果; return; } for (枚举所有选择) { 做选择; 标记; dfs(下一层); 撤销标记; } }
BFS模板：用queue存储当前层状态，while循环层序遍历。核心是visited数组防重复入队，否则会死循环。
二叉树遍历模板：前序、中序、后序递归三件套，不过大多数机试更常用的是层序遍历（BFS），以及根据前序+中序重建二叉树这类题目。这个重建逻辑是典型的高频考点，建议写一遍吃透。
图的最短路径模板：Dijkstra算法用优先队列优化是必背内容，复杂度O((V+E)logV)，在稀疏图上表现非常好。Floyd算法代码极其简单，就三层循环，适合稠密图的任意两点最短路，但要注意k在最外层，顺序错了就全错。
最小生成树模板：Prim算法适合稠密图，代码比Kruskal稍简单；Kruskal是边集排序+并查集，如果题目给的是边的集合，Kruskal更快，逻辑也更清晰。并查集模板顺手背下来，很多题都能用上。
动态规划模板：背包问题的经典写法、最长公共子序列、最长递增子序列、最大子段和。这些题目代码量不大，但要么状态转移方程写错，要么初始化不对。建议考前逐个过一遍，确保思路和代码完全一致。
高精度计算模板：高精度加法、减法、乘法、除法。机试有时候会考大数阶乘或者大数斐波那契，这类题目只要模板熟练，基本是送分题。
4.4 实战案例全流程拆解：从读题到AC
我拿一道典型的模拟题来做全流程演示，这个题目差不多是复试机试里出现过的难度。
题目：给定两个正整数a和b，求a+b的值。输入第一行为数据组数T，接下来每行两个整数a、b，输出每组数据的a+b，每组输出占一行。
听起来太简单了对吧？但就这么简单的题，也有人会写错。我们走一遍完整流程：
第一步，读题。明确输入的第一行是T，不是直接两个数。很多人上来就读a、b，忽略T，输出会直接错位。
第二步，确定数据范围。题目说正整数，没说大小，稳妥起见用long long存储，避免a和b都接近int上限时相加溢出。
第三步，确定读入方式。既然是T组数据，那就cin >> T，然后循环T次。
第四步，确定输出格式。每组输出占一行，中间不要多空行。
代码写出来是这样的：
#include <iostream> using namespace std; int main() { int T; cin >> T; while (T--) { long long a, b; cin >> a >> b; cout << a + b << endl; } return 0; }看着是不是很简单？但有三个细节需要注意：一是long long的格式说明符如果用scanf，是%lld，很多人写成%d就直接错；二是while(T--)这个写法很常见，但要确认T不会被后面代码改变；三是最后return 0，虽然C++不写也能过，但养成了规范习惯总是好事。
第二步，测试边界数据。我试着输入T=1，a和b都为0（虽然题目说正整数，但你不知道出题人的数据是否严格，测试边界无妨），程序输出0，正确。输入一个特别大的数，比如2147483647和2147483647，程序输出4294967294，没溢出，正确。如果T=3但实际只给了2行输入呢？程序会少做一次循环然后停止，不会崩溃——这也是处理非法输入的一种隐式方案。
第三步，提交前检查变量类型。如果这道题换成a、b的范围是10的100次方，那long long也不够，就得上高精度加法模板了。这也能看出来，简单题背后也一样考察基本功的厚度。
5. 考试中的高效Debug与心态管理
5.1 入门级调试手段：打印大法
很多同学平时依赖IDE的断点调试，觉得挺好用，但到了机试考场，时间紧、代码量大，有时候反而觉得断点调试太慢。我自己最常用的其实是打印法（printf调试法）。具体操作就是：在关键节点输出临时变量的值，看是否符合预期，逐步缩小错误范围。
比如，对于一个DFS迷宫问题，我会在每次进入新格子时输出坐标和方向，用来确认状态转移是否正确。对于一个动态规划问题，我会在每次计算完dp[i][j]后，打印dp数组的前几行，检查状态转移是否有明显异常。这个技巧虽然土，但效率极高，尤其在OJ判题不告诉你错在哪一组数据的时候，打印法能帮你快速定位逻辑错误。
但注意两个坑：第一，打印调试代码在提交前必须全部注释或删除，不然会多输出干扰信息，直接被判格式错误；第二，打印语句本身可能有副作用，比如printf调试时不小心将循环变量放在输出里改变了值，导致本来正确的逻辑出错。所以调试完记得仔细检查。
5.2 经典Bug排查清单
机试中最浪费时间的其实是低级Bug。这里整理一份高频Bug排查清单，遇到问题按清单顺序排查：
- 数组越界：尤其是字符串处理，字符数组长度不够，导致后面数据被覆盖。
- 死循环：while循环条件写错，或者循环变量没更新。
- 浮点数比较：涉及浮点数相等判断时，不要直接用==，要用fabs(a-b) < 1e-9。
- 类型溢出：int和long long混用时，强制转换要写在运算之前。
- 漏掉头文件：比如使用memset时没包含cstring，使用sort时没包含algorithm，编译直接报错。
- 文件名和类名：有的学校要求以Main命名主函数入口，或者提交时用特定文件名，注意看考场说明。
- 中文输入法残留：写代码时如果中文标点符号混进去，编译会报错，排查时先看光标附近的字符。
这个清单不是一次就能记住的，建议每次做题遇到报错，就把自己的低级错误记到笔记里，考前集中看一眼，非常有效。
5.3 时间分配与心态策略
机试的节奏感非常重要。我的建议是拿到题目后先花5分钟把所有题都看一遍，心里对整个难度有数：哪些是稳拿分的，哪些是需要花时间的，哪些是实在不行可以放弃的。这样分配时间的时候才有的放矢。
一个常用的时间分配策略是3-2-1法则：第一题如果简单，争取15到20分钟内拿下，把状态打出来；后面的中等题每题控制在25到35分钟，如果卡住超过10分钟就果断换题，回头有时间再来补；最后留足10到15分钟检查全部提交代码的编译情况。
考场里最忌讳的是跟一道题死磕。我见过太多人花了一个小时怼一道动态规划，结果后面两三道简单题完全没时间写，最后还不如把简单题全部拿下的人分数高。机试最终比的是总分，不是一道题的最优解。
还有心态问题。机试环境里面所有人都是独立做题，屏幕上有倒计时，旁边有键盘声，本来就很紧张。我在模拟测试的时候专门培养过“不受干扰”的能力：无论旁边的人敲得多快、翻页多频繁，我都专注在自己的题上。这种定力靠临时调节不现实，平时就要练。
5.4 提交前最后的检查流程
每次提交代码前，我建议按固定流程走一遍，这个流程能拦住90%的粗心错误。
第一步，确认读题是否正确：输入格式、输出格式、大小写、空行，和题目描述一字一句重新对一遍。
第二步，确认编译无误：在Dev-C++上按F11编译运行，或者在命令行g++编译，确保没有warning和error。有warning也值得注意，虽然能跑，但有时候warning背后就是未定义行为。
第三步，测试样例一定跑通，外加边界数据。如果题目给出样例，样例通过只是及格线，边界数据才是保障。
第四步，删除调试代码，提交。提交后如果被判错误，第一时间回头看题目有没有理解偏，再根据错误类型缩小范围。如果是Runtime Error，大概率是数组越界或除零；如果是Time Limit Exceeded，考虑换更高效算法或优化常数；如果是Wrong Answer，先在本地跑边界数据；如果是Presentation Error，检查输出格式的空格空行。
这个检查流程看起来简单，但很多人漏掉了“样例通过并不等于正确”这一点。OJ评测有多个隐藏测试点，只要有一组边界数据不过，就是零分。考前一定养成测试极端情况的习惯。
6. 常见问题与避坑实战
6.1 编译报错的那些雷
编译报错是最容易解决的，因为编译器会告诉你错误行号和原因。但有些报错信息初学者完全看不明白，我列几个常见的。
比如expected ';' before '}'，多半是前面少了个分号，或者花括号没配对。这种要顺着代码往上一行一行看，不要只看报错那行。再比如invalid conversion from 'int' to 'int*'，这是类型不匹配问题，常见于数组名和指针的混用。还有reference to 'left' is ambiguous的报错，多半是因为你的变量名和库函数命名空间冲突，换个变量名就好。
我实战中遇到最匪夷所思的报错是：代码在VS上编译通过，换到Dev-C++就报错。后来发现是VS用了微软特有的头文件或扩展语法。所以考前务必统一编译环境，或者至少养成在两种环境都编译验证的习惯。
6.2 运行无误但答案错误，怎么排查
如果程序编译通过、运行不崩溃，但提交判Wrong Answer，这说明是逻辑层面的问题。我的排查步骤是：
第一步，重读题目，确认是否遗漏了某些条件。很多Wrong Answer其实源于读题漏了某个关键字，比如“升序”还是“非降序”，“正整数”还是“非负整数”。
第二步，为代码设计几组简单的手工测试数据，一步步跟踪计算结果。小数据可以手算，核对程序输出是否一致。
第三步，检查排序条目的比较逻辑，尤其是排序规则是自定义的，很容易出现比较函数写得不对，导致排序结果不符合题意。
第四步，检查状态数组或标记数组是否重置干净。多组数据输入时，上一次计算留下来的脏数据会让下一组结果算错。这个问题极其常见，解决办法是在每次循环开始时全部清零或重新初始化。
第五步，检查变量是否重复使用。比如在两个循环里都用同一个变量i，但外层循环修改了内层循环的循环变量，导致结果错乱。这个可以靠“每个循环尽量使用不同变量名”来规避。
6.3 超时（TLE）的优化思路
很多人在机试中遇到Time Limit Exceeded就慌，其实优化思路是有固定套路的：
第一步，检查算法复杂度。如果题目n范围是10的5次方，而你写了O(n²)的暴力算法，一定会超时。这时候要换思路，比如改用二分、前缀和、双指针或者使用哈希表。
第二步，检查输入输出效率。用cin/cout时，如果没有加上ios::sync_with_stdio(false)和cin.tie(0)，大数据量时会比scanf/printf慢很多。我之前实测过，加上这两句之后cin的速度可以和scanf接近。注意，这个优化对C++的流输入输出非常有效，强烈建议写代码时统一加上。
第三步，检查是否有多余的重计算。比如一个值在循环体内反复计算且不变，提到循环外面就能节省大量时间。
第四步，检查剪枝是否做到位。搜索类题目，DFS和BFS不剪枝和剪枝的差距是指数级的。
这些优化不一定每次都能救回来，但大部分TLE问题都可以通过这些手段解决。
6.4 考前一周的“保温”操作
考前一周最重要的事情不是刷难题，而是保温。每天保持一定的代码手感。
我考前一周的安排是：每天固定做2道简单题和1道中等题，时间控制在1小时左右。简单题用来保持手感和自信心，中等题用来巩固模板。做完之后重点看错题和笔记，把所有容易犯的错误再默读一遍。
此外，考前要把高频模板完整抄写一遍：快速幂、并查集、Dijkstra、DFS、BFS、DP背包、高精度加法。抄写不是为了背诵，是为了熟练。考试时即使不能完整默写，也知道关键逻辑在哪里，哪怕推导一下也能快速恢复。
还有一个细节：如果考场允许带纸质资料，把整理的模板打印出来带进去，会安心很多。但注意提前确认考场规则，有些学校禁止，有些学校允许，别因为这种小事影响了状态。
7. 复试机试的加分项与经验总结
7.1 代码规范比你想象的更重要
虽然OJ评测不看你代码风格，但复试机试不完全是机器评分。部分学校会在机试之后安排面试环节，面试官会翻看你写的代码，考察你的思路和编程习惯。所以平时就要养成写注释的习惯，关键函数、关键变量的含义写清楚，核心逻辑用注释标注出来。如果面试环节被问到你代码里的某个细节，注释能帮你快速回忆当时的思路。
另外，函数命名和变量命名尽量做到见名知意。不要写a、b、c这种无意义的变量名（哪怕是为了省时间），网上阅卷和面试时观感很差。用sum、cnt、visited、dp这样有语义的名字，不会多花太多时间，但能看出一个程序员的基本素养。
7.2 机器评测之外的“隐藏规则”
有些机试系统是实时显示的，你的每次提交都会被记录，代码运行时间、内存消耗等指标都会呈现在测评页面上。面试官可能会看你的提交次数和首次AC时间。如果你反复提交十几次才通过，会给面试官留下“调试能力一般”的印象。所以平时刷题就要争取低提交次数，训练自己在提交前把代码检查到位。
还有一个小规则：如果你的代码被评测系统评测失败，可能是编译错误、超时、错误、运行错误等不同状态。不同的判题系统对相同错误的分类命名可能不同，但大体一致。考前务必搞清楚目标院校所用的OJ系统的错误提示含义，不然看到“Rejected”就茫然无措，浪费时间。
7.3 复试机试的保守策略与得分思维
机试拿分有一些通用的策略，掌握住之后可以提高整体得分率。
策略一：难度跳跃式做题。先把所有题都看一遍，从最简单的开始做，保证每道题都有得分记录。有些同学喜欢先做难题，结果卡住后情绪崩溃，简单题也没做好，得不偿失。
策略二：部分分思维。即使一道题不会做完整解法，也可以尝试暴力解法拿部分分。很多OJ平台对暴力解法会有一部分测试点能通过，能得一分是一分。
策略三：如果题目明确区分了多个子任务，优先完成最容易的子任务。比如“第一问必答，第二问选答”，先把第一问稳稳拿下，再考虑第二问，不要从后往前做。
策略四：考试最后5分钟不要写新题，全部用来检查已写代码。检查所有提交是否都已确认、文件名是否符合要求、代码中是否有调试残留。
7.4 最后留一句实在话
机试这个东西，本质上拼的是熟练度和细节把控能力。聪明不聪明反而排在后面。你花在刷题上的每一分钟都不会白费，只要策略正确、环境熟悉、模板在手、心态稳住，绝大多数人的机试成绩都会对得起自己的付出。我到现在还记得自己考场上那道题——我用了十分钟等紧张感过去，然后按平时的节奏一道一道做下去，全程没有去关心别人的屏幕。这种专注的状态，靠的就是平时的限时训练。
如果你正在备考，希望这篇回顾能帮你少走一点弯路。把基础打牢，把模板备好，把边界条件想全，把环境提前适配好，剩下的就是相信自己。考场上的那几个小时，终究会变成你研究生生涯第一道跨过去的门槛。
