企业官网建设流程全解析

1. 从“测验汇总”四个字里能读出什么

看到“程序设计与算法（一）测验汇总(2021夏季)”这个标题，很多人的第一反应是：这不就是一份题集吗？但如果你真的带过课、或者自己从头到尾刷过一遍这类测验，就会发现事情远没有这么简单。一份好的测验汇总，本质上是一张知识点的拓扑图——它告诉你哪些概念是必须掌握的、哪些是容易混淆的、哪些是看起来会了但一考就错的。

我前后完整做过三遍这类测验，第一遍是裸做，第二遍是带着“为什么错”的复盘心态做，第三遍是尝试用不同的解法去验证同一道题。三遍下来最大的感受是：测验题的价值不在于答案本身，而在于它暴露出来的思维盲区。比如同样是循环结构，有人错在边界条件，有人错在变量作用域，有人错在循环不变量的理解——这些错误背后对应的是完全不同的知识漏洞。

这篇文章适合三类人看：正在学程序设计基础课的学生、准备考研或转行需要补算法基础的从业者、以及想系统梳理自己编程基本功的开发者。我会把测验中反复出现的核心考点拆开揉碎，讲清楚每个知识点“为什么这样考”“容易在哪里翻车”“怎么练才能真正掌握”，而不是简单地贴答案。

需要提前说明的是，本文不会逐题罗列答案，而是按照知识模块来组织。因为逐题讲答案的收益很低——你下次遇到变体题还是不会。只有把底层逻辑吃透，才能做到“做一道题会一类题”。

2. 变量、表达式与输入输出：最基础的地方最容易丢分

2.1 为什么“简单题”反而错误率最高

测验汇总里有一类题，看起来就是简单的变量赋值和输出，但实际统计下来，这类题的首次正确率往往不到七成。原因很反直觉：越基础的题，越依赖对细节的精确记忆，而人脑对“看起来简单”的东西天然会降低注意力。

举个例子，整数除法和浮点除法的区别。在C/C++里，5/2的结果是2而不是2.5，这个规则大家都知道，但一到实际写题的时候，很多人会忘记把其中一个操作数转成浮点型。再比如printf的格式控制符，%d对应int，%f对应float/double，%c对应char，看起来是常识，但一旦变量类型和格式符不匹配，输出的就是完全不可预期的垃圾值。

我在复盘时总结了一个检查清单，每次写完这类题都过一遍：

• 参与运算的变量类型是否一致？如果不一致，隐式转换的方向是什么？
• 除法运算中，除数和被除数是否至少有一个是浮点型？
• 输出格式符和变量类型是否严格对应？
• 输入时是否考虑了缓冲区残留的换行符或空格？

提示：很多测验题会在输入输出格式上设置“陷阱”，比如要求输出保留两位小数但没明确说四舍五入规则，或者输入数据之间用逗号分隔而不是空格。读题时把格式要求圈出来，比写完再检查有效得多。

2.2 表达式求值顺序：一个被严重低估的考点

表达式求值顺序是测验中反复出现的难点。很多人以为a + b * c就是先算乘法再算加法，这没错，但一旦涉及自增自减运算符、函数调用、赋值运算的混合，事情就变得复杂了。

比如i = i++ + ++i这种表达式，不同编译器可能给出不同结果，因为C/C++标准对这类“同一变量在同一个表达式中被多次修改”的行为定义为未定义行为。测验中如果出现这类题，考的不是“正确答案是什么”，而是“你是否知道这是未定义行为”。

我在实际做题时养成了一个习惯：凡是遇到一个表达式里同一个变量出现两次以上且带有副作用运算符的，直接标记为“未定义行为”，不去纠结具体结果。这个判断本身就是得分点。

再比如短路求值。a && b中如果a为假，b根本不会被求值。这个特性经常被用来出题，比如if (ptr != NULL && ptr->value > 0)，如果ptr为空，后面的解引用就不会执行。理解短路求值不仅能做对题，更是写出健壮代码的基本功。

2.3 类型转换的隐式规则与常见陷阱

隐式类型转换的规则可以用一句话概括：低精度向高精度看齐。char转int，int转float，float转double，这是自动进行的。但反过来，高精度转低精度会丢失信息，而且编译器可能只给一个警告甚至不报错。

测验中常见的考法是这样的：

int a = 10; float b = 3.5; double c = a / b + 1.2;

这里a / b中a会自动转成float，结果是float，再加1.2时又会转成double。如果你不清楚这个链条，就可能误以为结果是整数运算。

还有一个经典陷阱是unsigned和signed的混合运算。当一个int和一个unsigned int做运算时，int会被转成unsigned int，如果这个int是负数，就会变成一个非常大的正数。这类题在测验中出现的频率很高，而且在实际开发中也是真实的bug来源。

3. 控制结构：循环与分支的边界思维训练

3.1 for循环的三个表达式到底怎么执行

for循环的语法for(初始化; 条件; 更新)看起来简单，但测验中经常考察它的精确执行顺序。标准流程是：初始化只执行一次，然后判断条件，条件为真则执行循环体，循环体结束后执行更新表达式，然后再判断条件，如此反复。

很多人出错的地方在于混淆了“更新”和“循环体”的顺序。比如下面这段代码：

int i; for (i = 0; i < 5; i++) { printf("%d ", i); }

输出是0 1 2 3 4，这没问题。但如果把i++写到循环体里面，同时更新表达式留空，行为就完全不同了。测验中经常用这种变体来考察你是否真正理解for循环的执行模型。

还有一个高频考点是循环变量的作用域。在C99之后，for(int i = 0; ...)中的i只在循环内有效，循环外访问会编译错误。但在老标准或某些编译器的宽松模式下，这个i可能在循环外仍然可见。测验中如果出现这类题，考的是你对标准演进的了解。

3.2 while和do-while的本质区别

while是先判断后执行，do-while是先执行后判断。这个区别大家都知道，但真正体现在题目里的时候，很多人会忽略一个关键点：do-while至少执行一次循环体。

这个特性在某些场景下非常有用，比如菜单驱动的程序，你希望用户至少看到一次菜单再决定是否退出。测验中常见的考法是给出一段do-while代码，问循环体执行了多少次。如果你只盯着条件表达式看，很容易忽略“至少一次”这个规则。

我在做题时总结了一个判断方法：看循环条件中使用的变量是否在循环体内部被修改。如果条件变量在循环体内部才被赋值，那么while循环可能一次都不执行，而do-while至少执行一次。这个判断方法比死记规则更可靠。

3.3 switch语句的穿透效应与break的位置

switch语句的穿透（fall-through）是测验中的常客。如果某个case后面没有break，程序会继续执行下一个case的代码，直到遇到break或者switch结束。

这个特性有时候是被故意利用的，比如多个case共享同一段处理逻辑：

switch (grade) { case 'A': case 'B': printf("优秀"); break; case 'C': printf("及格"); break; default: printf("不及格"); }

但更多时候，漏写break是一个bug。测验中经常给出一段缺少break的switch代码，问最终输出是什么。做这类题的关键是在脑子里模拟执行路径，而不是凭感觉猜。

还有一个容易忽略的点是default的位置。default可以放在switch的任何位置，不一定要在最后。如果default不在最后且没有break，同样会发生穿透。这个考点在测验中出现的频率不低，但很多人因为习惯性地认为default在最后而做错。

3.4 嵌套循环的执行次数计算

嵌套循环的执行次数是测验中计算量最大的题型之一。比如：

for (int i = 1; i <= n; i++) { for (int j = i; j <= n; j++) { // 循环体 } }

内层循环的执行次数是n + (n-1) + ... + 1 = n(n+1)/2。这个计算本身不难，但测验中经常把内层循环的起始条件改成j = 1或者j = i * 2之类的变体，这时候就需要重新推导。

我的经验是：不要试图背公式，而是画出执行轨迹表。把i和j的每一组取值列出来，规律自然就显现了。这个方法看起来笨，但在考试时间充裕的情况下，比套公式更不容易出错。

4. 数组与字符串：内存布局决定了一切

4.1 数组下标越界的隐蔽性

数组下标从0开始，这个规则不需要记忆，但下标越界的后果却经常被低估。在C/C++中，访问数组越界不会抛出异常，而是会读写相邻内存区域的数据。这意味着程序可能不崩溃，但结果是完全错误的。

测验中常见的考法是给出一段数组操作的代码，问输出结果。如果代码中存在越界访问，那么“正确答案”取决于内存布局，而内存布局又取决于编译器和运行环境。这类题实际上考的是你是否能识别出越界行为，而不是让你去猜具体值。

我在做题时遇到数组相关的代码，第一件事就是检查所有下标表达式的取值范围。特别是循环中的i <= n和i < n，一字之差就是越界和不越界的区别。

4.2 二维数组的行列存储顺序

二维数组在内存中是按行存储的，也就是说a[0][0]后面紧跟着a[0][1]，而不是a[1][0]。这个知识点在测验中经常以“计算某个元素的地址”的形式出现。

比如有一个int a[3][4]，问a[1][2]的地址相对于a[0][0]偏移了多少个字节。计算方法是：(1 * 4 + 2) * sizeof(int)。如果sizeof(int)是4，那么偏移就是24字节。

这个计算的关键是理解行优先存储的含义。如果你把它想象成一个表格，行是外层下标，列是内层下标，那么内存中的排列就是一行一行地铺开。这个直觉建立起来之后，类似的题都不会做错。

4.3 字符串的结束符与缓冲区溢出

字符串在C语言中是以\0结尾的字符数组。这个知识点本身不难，但测验中经常考察strlen和sizeof的区别。strlen计算的是从起始位置到第一个\0之间的字符数，不包括\0；sizeof计算的是整个数组占用的字节数，包括\0和未使用的空间。

比如：

char str[20] = "hello"; printf("%d %d", strlen(str), sizeof(str));

输出是5 20。这个例子很典型，但测验中会把它包装得更复杂，比如在字符串中间手动插入\0，或者用字符数组初始化一个没有结束符的字符串。

缓冲区溢出是另一个高频考点。当使用strcpy、strcat、sprintf等函数时，如果目标缓冲区不够大，就会覆盖相邻内存。测验中经常给出一段存在溢出风险的代码，问“这段代码有什么问题”。识别这类问题的关键是检查目标缓冲区的大小是否足够容纳源数据加上结束符。

注意：在实际开发中，应该优先使用strncpy、snprintf等带有长度限制的函数。但在测验中，你需要先判断出题目使用的是哪种函数，再分析其行为。

4.4 数组作为函数参数时的退化行为

数组作为函数参数时，会退化为指向首元素的指针。这意味着在函数内部无法通过sizeof获取数组的长度。这个知识点在测验中经常以“以下代码的输出是什么”的形式出现。

void func(int arr[]) { printf("%d", sizeof(arr)); } int main() { int a[10]; printf("%d ", sizeof(a)); func(a); }

在64位系统上，sizeof(a)是40（10个int），而sizeof(arr)是8（一个指针的大小）。这个差异是很多bug的根源。

我在做题时遇到数组传参的代码，会立刻在脑子里把int arr[]替换成int *arr，这样就能避免被“数组”这个词误导。这个思维习惯帮我避开了很多陷阱。

5. 函数与递归：调用栈是理解一切的关键

5.1 值传递与地址传递的混淆点

C语言只有值传递，指针传递本质上也是值传递——传递的是地址的值。这个知识点在测验中经常以“以下代码能否交换两个变量的值”的形式出现。

void swap(int a, int b) { int temp = a; a = b; b = temp; }

这段代码不能交换调用者的变量，因为a和b是形参，是实参的副本。要真正交换，需要传递指针：

void swap(int *a, int *b) { int temp = *a; *a = *b; *b = temp; }

测验中经常把这两种写法混在一起考，比如给出一个部分正确的交换函数，问哪里有问题。识别这类问题的关键是看函数内部是否通过解引用修改了调用者的内存。

5.2 递归的执行轨迹与栈帧变化

递归是测验中的重头戏。很多人能写出递归函数，但说不清楚递归的执行过程。比如经典的斐波那契数列：

int fib(int n) { if (n <= 1) return n; return fib(n-1) + fib(n-2); }

问fib(5)被调用了多少次。这类题需要画出递归树，数一数每个节点被访问的次数。fib(5)会调用fib(4)和fib(3)，fib(4)又会调用fib(3)和fib(2)，以此类推。最终fib(5)被调用1次，fib(4)被调用1次，fib(3)被调用2次，fib(2)被调用3次，fib(1)被调用5次，fib(0)被调用3次。

这个计算过程看起来繁琐，但它是理解递归效率问题的关键。fib(5)只需要15次调用，但fib(40)的调用次数就超过了一亿次。这就是为什么实际开发中要用动态规划或记忆化搜索来优化递归。

5.3 递归与迭代的转换思路

测验中经常要求把递归函数改写成迭代形式，或者反过来。这个转换的核心是找到递归的“状态”和“终止条件”，然后用循环变量来模拟状态的变化。

以阶乘为例，递归写法是：

int factorial(int n) { if (n <= 1) return 1; return n * factorial(n-1); }

迭代写法是：

int factorial(int n) { int result = 1; for (int i = 2; i <= n; i++) { result *= i; } return result; }

转换的关键是把递归中“从n往下乘”的过程，改成迭代中“从2往上乘”的过程。方向反了，但结果一样。

我在做题时总结了一个技巧：先写出递归的数学定义，再把定义中的递归调用替换成循环变量。比如阶乘的数学定义是f(n) = n * f(n-1)，迭代版本就是把f(n-1)替换成上一轮循环的结果。

5.4 函数声明与定义分离时的链接问题

当函数声明和定义分离时，如果声明和定义的签名不一致，就会出现链接错误。测验中经常给出一段代码，问“这段代码能否编译通过”。

比如：

// 声明 int add(int a, int b); // 定义 double add(double a, double b) { return a + b; }

这段代码在C++中会因为函数重载而编译通过，但在C语言中会报错，因为C不支持函数重载。测验中如果出现这类题，考的是你对语言特性的理解。

还有一个常见问题是函数声明了但没有定义。这会导致链接错误，而不是编译错误。编译阶段只检查语法，链接阶段才检查符号是否存在。理解这个区别对于排查实际问题很有帮助。

6. 指针与内存：从“知道”到“真正理解”的分水岭

6.1 指针的本质：一个存放地址的变量

指针是程序设计与算法课程中最难的部分，没有之一。很多人学完指针之后，能写出int *p = &a;这样的代码，但说不清楚*p和p的区别，更说不清楚**p是什么意思。

指针的本质很简单：它是一个变量，只不过这个变量里存的是另一个变量的地址。p是指针变量本身，它的值是地址；*p是解引用操作，得到的是这个地址上存放的值。

理解了这个本质，很多看似复杂的指针题就变得清晰了。比如：

int a = 10; int *p = &a; int **pp = &p; printf("%d", **pp);

pp是指向指针的指针，*pp得到p，**pp得到a的值。逐层解引用，逻辑很清晰。

6.2 指针与数组的等价关系及其边界

在大多数表达式中，数组名会退化为指向首元素的指针。所以a[i]等价于*(a + i)，&a[i]等价于a + i。这个等价关系是指针运算的基础。

但有一个例外：sizeof(a)和&a中，数组名不会退化。sizeof(a)得到的是整个数组的大小，&a得到的是指向整个数组的指针，而不是指向首元素的指针。

测验中经常利用这个例外来出题。比如：

int a[5]; printf("%d %d", sizeof(a), sizeof(&a));

在64位系统上，输出是20 8。sizeof(a)是5个int的大小，sizeof(&a)是一个指针的大小。

6.3 动态内存分配的三步走策略

动态内存分配是测验中的高频考点，也是实际开发中bug的重灾区。标准的三步走策略是：分配、使用、释放。

int *p = (int *)malloc(n * sizeof(int)); if (p == NULL) { // 处理分配失败 } // 使用p free(p); p = NULL;

测验中经常考察的细节包括：malloc的参数是字节数而不是元素个数；malloc返回的是void *，需要强制类型转换；free之后要把指针置空，防止悬空指针。

还有一个容易忽略的点是内存泄漏。如果分配了内存但没有释放，程序运行时间长了就会耗尽内存。测验中经常给出一段存在内存泄漏的代码，问“这段代码有什么问题”。识别这类问题的关键是检查每个malloc是否有对应的free。

6.4 指针作为函数返回值的陷阱

函数可以返回指针，但返回的指针不能指向函数内部的局部变量。因为局部变量在函数返回后就被销毁了，返回的指针就变成了悬空指针。

int *func() { int a = 10; return &a; // 错误：返回局部变量的地址 }

正确的做法是返回动态分配的内存，或者返回静态变量或全局变量的地址。测验中经常给出一段返回局部变量地址的代码，问“这段代码有什么问题”。识别这类问题的关键是看返回的指针指向的内存是否在函数返回后仍然有效。

我在做题时遇到函数返回指针的情况，会立刻检查这个指针指向的是堆内存、静态内存还是栈内存。只有堆内存和静态内存才是安全的。

7. 结构体与文件操作：从单变量到复合数据的跨越

7.1 结构体的内存对齐规则

结构体的内存布局不是简单地把成员变量的大小相加，而是要考虑内存对齐。比如：

struct Example { char c; int i; double d; };

在64位系统上，这个结构体的大小不是1 + 4 + 8 = 13，而是24。因为int需要4字节对齐，double需要8字节对齐，所以char后面会有3字节的填充，int后面会有4字节的填充。

测验中经常考察结构体大小的计算。我的经验是：按照成员声明顺序，逐个计算偏移量，确保每个成员的偏移量是其对齐大小的整数倍。最后结构体的总大小还要是最大对齐大小的整数倍。

7.2 结构体指针与箭头运算符

访问结构体成员有两种方式：用点运算符访问结构体变量，用箭头运算符访问结构体指针。

struct Point p = {1, 2}; struct Point *ptr = &p; printf("%d %d", p.x, ptr->x);

ptr->x等价于(*ptr).x。箭头运算符只是语法糖，让代码更简洁。

测验中经常把这两种方式混在一起考，比如(*ptr).x和ptr->x哪个是正确的。实际上两个都正确，但箭头运算符更常用。

7.3 文件读写的基本流程与常见错误

文件操作的基本流程是：打开文件、读写文件、关闭文件。

FILE *fp = fopen("data.txt", "r"); if (fp == NULL) { // 处理打开失败 } // 读写操作 fclose(fp);

测验中经常考察的细节包括：fopen的第二个参数（"r"、"w"、"a"等）的含义；fscanf和fprintf的返回值；fclose的必要性。

还有一个容易忽略的点是文件打开模式的区别。"w"模式会清空文件内容，"a"模式会在文件末尾追加。如果误用了"w"模式，可能会丢失原有数据。

7.4 结构体数组的排序与查找

结构体数组的排序是测验中的综合题型，考察结构体、数组、指针、函数等多个知识点的综合运用。比如按某个成员排序：

struct Student { char name[20]; int score; }; void sort(struct Student arr[], int n) { for (int i = 0; i < n - 1; i++) { for (int j = 0; j < n - 1 - i; j++) { if (arr[j].score > arr[j+1].score) { struct Student temp = arr[j]; arr[j] = arr[j+1]; arr[j+1] = temp; } } } }

这段代码实现了按分数升序排列。测验中经常要求改成降序，或者按多个字段排序。关键是要理解比较函数的逻辑决定了排序结果。

我在做这类题时，会先把比较逻辑用自然语言写出来，比如“如果前一个的分数大于后一个的分数，就交换”，然后再翻译成代码。这样不容易出错。

8. 算法初步：排序与查找的实战细节

8.1 冒泡排序的优化与边界条件

冒泡排序是最基础的排序算法，但测验中经常考察它的优化版本。标准冒泡排序每一轮都会把最大的元素“冒”到最后，但如果某一轮没有发生任何交换，说明数组已经有序，可以提前结束。

void bubbleSort(int arr[], int n) { for (int i = 0; i < n - 1; i++) { int swapped = 0; for (int j = 0; j < n - 1 - i; j++) { if (arr[j] > arr[j+1]) { int temp = arr[j]; arr[j] = arr[j+1]; arr[j+1] = temp; swapped = 1; } } if (!swapped) break; } }

这个优化在数组已经有序的情况下，时间复杂度从O(n²)降到O(n)。测验中经常问“这个优化在什么情况下最有效”，答案就是“数组已经基本有序”的情况。

8.2 二分查找的边界陷阱

二分查找的思路很简单，但边界条件极其容易写错。常见的错误包括：mid的计算方式导致死循环、left和right的更新方式不一致、循环条件写成left < right而不是left <= right。

int binarySearch(int arr[], int n, int target) { int left = 0, right = n - 1; while (left <= right) { int mid = left + (right - left) / 2; if (arr[mid] == target) return mid; if (arr[mid] < target) left = mid + 1; else right = mid - 1; } return -1; }

这段代码中有几个关键点：mid用left + (right - left) / 2而不是(left + right) / 2，是为了防止整数溢出；left和right的更新都是mid + 1和mid - 1，确保区间缩小；循环条件是left <= right，确保区间为空时退出。

测验中经常给出一个边界条件写错的二分查找，问“这个函数在什么情况下会出错”。识别这类问题的关键是手动模拟target在数组两端的情况。

8.3 选择排序与插入排序的适用场景

选择排序和插入排序都是O(n²)的算法，但它们的适用场景不同。选择排序的交换次数最少，适合交换成本高的场景；插入排序在数组基本有序时效率很高，适合增量排序。

测验中经常问“哪种排序算法适合什么场景”。我的回答思路是：看数据的特点和操作的成本。如果数据量小且基本有序，插入排序是最优选择；如果交换操作代价高，选择排序更合适；如果要求稳定性，冒泡排序和插入排序是稳定的，选择排序是不稳定的。

8.4 时间复杂度的分析方法

时间复杂度是算法分析的核心概念。测验中经常要求分析一段代码的时间复杂度。分析方法是：找到执行次数最多的那条语句，用n表示它的执行次数。

比如：

for (int i = 0; i < n; i++) { for (int j = 0; j < n; j++) { // 常数时间操作 } }

外层循环执行n次，内层循环也执行n次，所以总执行次数是n²，时间复杂度是O(n²)。

对于递归算法，时间复杂度的分析需要用到递归方程。比如归并排序的递归方程是T(n) = 2T(n/2) + O(n)，解出来是O(n log n)。这个分析过程在测验中经常出现，需要熟练掌握。

9. 测验复盘的正确姿势：从错题到知识网络

9.1 错题分类的四个维度

做完测验之后，最重要的不是看分数，而是对错题进行分类。我通常按四个维度来分：

• 概念不清：对某个知识点的定义理解有误，比如把strlen和sizeof搞混。
• 细节遗漏：知道概念但忽略了边界条件，比如循环的<=写成了<。
• 思维盲区：完全没想到的考点，比如未定义行为、内存对齐。
• 粗心大意：看错题目、抄错数字、漏看条件。

这四个维度的复习策略完全不同。概念不清需要重新看书，细节遗漏需要做专项练习，思维盲区需要扩展知识面，粗心大意需要调整做题习惯。

9.2 从单题到知识网络的扩展方法

每道错题都是一个知识网络的入口。比如你错了一道关于指针的题，不要只看这道题的解析，而是要把指针相关的知识点都串一遍：指针的定义、指针运算、指针与数组、指针与函数、指针与结构体、动态内存分配。

我的做法是：以错题为中心，画一张思维导图。中心是错题考察的知识点，周围是相关的概念、常见错误、典型例题。这张图越画越厚，但你的知识网络也越来越密。

9.3 二刷和三刷的策略差异

第一遍做测验的目的是暴露问题，第二遍的目的是验证问题是否解决，第三遍的目的是巩固和提速。

二刷时，我会重点做第一遍做错的题和当时蒙对的题。如果第二遍还是错，说明这个知识点没有真正掌握，需要回到教材重新学习。

三刷时，我会限时完成，模拟考试环境。这时候关注的不是“会不会”，而是“快不快”和“稳不稳”。很多题不是不会做，而是时间不够或者粗心做错。三刷的目的就是把这些非知识性失分降到最低。

9.4 把测验题改造成自己的练习题

测验题的数量有限，但你可以把它们改造成无限多的练习题。方法很简单：改变题目条件，重新求解。

比如一道关于循环的题，把循环次数从5改成10，把步长从1改成2，把条件从<改成<=，看看自己还能不能做对。再比如一道关于数组的题，把一维数组改成二维数组，把int改成char，看看有什么变化。

这个改造过程本身就是一种深度学习。你不仅要知道答案是什么，还要知道答案为什么是这个，以及条件变化后答案会怎么变。

10. 一些踩过坑之后才明白的事

10.1 不要迷信“标准答案”

测验汇总里的答案不一定是对的。我至少遇到过三次答案有误的情况，有的是因为编译器差异，有的是因为题目本身有歧义。遇到这种情况，不要怀疑自己，而是去查标准文档或者实际运行验证。

提示：如果一道题的答案和你的理解不一致，先别急着改答案，而是把代码实际跑一遍。实践是检验真理的唯一标准。

10.2 编译器的警告不是摆设

很多人做测验时习惯忽略编译器的警告，只要程序能跑就行。但很多测验题考察的正是那些“能跑但行为未定义”的情况。把编译器的警告级别调到最高（比如-Wall -Wextra），你会发现很多隐藏的问题。

10.3 手写代码和上机调试是两回事

测验通常是手写代码，没有编译器帮你检查语法错误。这意味着你需要对语言的语法规则非常熟悉，不能依赖IDE的自动补全和错误提示。我的建议是：平时练习时就有意识地手写代码，写完再上机验证。这样能培养对语法细节的敏感度。

10.4 算法题的核心是“模拟”

很多算法题看起来复杂，但本质上就是让你模拟一个过程。比如模拟一个队列的入队出队、模拟一个栈的压栈弹栈、模拟一个递归的调用过程。把模拟过程在纸上画出来，比在脑子里空想有效得多。

我在做这类题时，会准备一张草稿纸，把每一步的状态变化都写下来。虽然看起来慢，但正确率比心算高得多。而且这个习惯在实际开发中同样有用——调试复杂逻辑时，把状态变化打印出来或者画出来，比盯着代码看有效得多。

10.5 测验分数不等于编程能力

最后说一个可能有点反直觉的观点：测验分数高不代表编程能力强，测验分数低也不代表你学不会编程。测验考察的是对语言细节和算法原理的掌握程度，而实际编程更多考察的是解决问题的能力、代码组织能力和调试能力。

我见过测验满分但写不出一个完整项目的人，也见过测验勉强及格但能独立完成复杂系统的人。测验只是学习过程中的一个检查点，不是终点。把测验中暴露出来的问题解决掉，比追求高分更有价值。