企业官网建设流程全解析

简介：东北大学数据结构实验报告（docx 文档）以顺序表与链表实现约瑟夫环问题为主线，完整覆盖线性表基本操作、链式存储结构设计及循环链表应用，适合数据结构课程学习者、考研复试或实验报告撰写参考。压缩包内含 1 个 docx 文件，大小约 502KB，排版规范、代码注释清晰，便于直接查看或修改复用。报告结构完整，包含实验目的、抽象数据类型设计、主要函数代码、复杂度分析、调试记录与实验结果总结。核心算法涵盖链表节点定义、创建循环链表、显示链表内容、按密码删除结点等步骤，并逐一对各函数进行时间与空间复杂度分析；同时附有调试过程中遇到的问题及改进方案，如指针初始化、循环链表闭合时机、头结点处理等，对理解约瑟夫环的边界条件与链表操作细节很有帮助。实验环境为 Windows 7 与 Visual Studio 2017，具有较强的可复现性。目前已有 293 人学习，报告内容真实完整，可作为东北大学数据结构实验一“顺序表和链表的应用”的优质参考资料。

1. 一份东北大学数据结构实验报告，能值回多少票价

在大三下学期结束前，我翻出自己写得最厚的一门课作业：数据结构实验报告。封面写着“东北大学”，页数是74页，里面有线性表、栈队列、树、图、排序、查找，几乎每章都有一份可运行的C语言代码和对应的测试输出。这份报告我当时交了作业就扔在网盘里，直到准备考研复习数据结构时重新翻出来，才发现它远比我想象的值钱——考研数据结构408里那些图、数组、排序算法，我在实验报告里都亲手调过、改过、踩过坑，复习时看一遍代码比看十遍教材都记得牢。

这就是一篇数据结构实验报告的真实价值：它不是教务处要求的一坨纸，而是你亲手把“算法怎么实现”走了一遍的证据。你可能会问，网上有那么多现成源码包，为什么要自己做？答案很简单，期末考试和考研复试问的是“为什么这段代码不写free就内存泄漏”“顺序表和链表在哪个场景翻车”，代码不亲手敲进去、跑出异常、再修好，这些问题你根本答不上来。

这篇文章写给正在做数据结构实验、或者准备用它来复习考研408的人。我会按照东北大学课程常见的实验设计思路，说清楚一份实验报告该怎么做、每个实验的代码骨架长什么样、参数怎么调、测试数据怎么给、以及最容易被扣分的那些细节。你不用照着某个特定模板抄，按这个思路走，不管是哪个学校的实验报告，你都能写出一份拿得出手、自己也看得懂的东西。

2. 从实验指导书里拆出必考模块：先把“做什么”变成“考什么”

写实验报告的第一步不是打开Dev-C++或者VS Code，而是把实验指导书里的题目翻译成“这个实验在考哪个数据结构、哪个算法”。一份合格的实验报告，本质上就是在回答这个翻译题。东北大学数据结构课程的实验设计一般围绕三个层次展开：线性结构（顺序表、链表、栈、队列）、树形结构（二叉树、哈夫曼树）、图形结构（图的遍历、最短路），最后追加排序和查找的综合实验。这个顺序恰好和考研数据结构408的大纲是同轴的。

2.1 线性表实验：别只写“能跑”，要写清楚“为什么选它”

线性表实验是开胃菜，但恰恰是最多人在这里翻车的。常见的题目是“学生信息管理系统”或者“多项式加减法”，用顺序表或链表实现。大部分人的做法是选顺序表，因为数组好写、不用指针、不用malloc。但这样写实验报告，等于把送分题做成了送命题——因为实验报告里必须回答一个问题：为什么这个场景选顺序表而不是链表？

我的建议是，这个实验就做两个版本。第一版用顺序表实现，第二版把插入删除操作改成链表实现，然后把两组操作的时间对比贴出来。这样做有几个实际好处：第一，你亲手体会了“顺序表插入要移动n/2个元素”这句话到底意味着什么，当你插入10万个学生信息时，那种卡顿感是教材上的复杂度公式给不了的；第二，实验报告的“结果分析”栏你有的写了，不用凑字。

代码骨架我一般会这样组织，顺序表核心就三块：初始化、插入、删除。下面是一个最小可用的顺序表插入实现，我在实验里会把它扩展成学生信息的增删查改。

#include <stdio.h> #include <stdlib.h> #define MAXSIZE 100 typedef struct { int id; char name[20]; } Student; typedef struct { Student data[MAXSIZE]; int length; } SeqList; void listInsert(SeqList *L, int pos, Student s) { // 参数说明：pos是插入位置，从1开始计数 // 插入前必须检查表是否已满，以及pos是否越界 if (L->length >= MAXSIZE) { printf("表已满，无法插入\n"); return; } if (pos < 1 || pos > L->length + 1) { printf("插入位置非法\n"); return; } // 从最后一个元素开始，逐个向后移动 // 这里就是顺序表插入代价最高的地方，移动次数是 n - pos + 1 for (int i = L->length; i >= pos; i--) { L->data[i] = L->data[i - 1]; } L->data[pos - 1] = s; L->length++; }

这段代码里最值得注意的是那个for循环：从末尾往前移动，这样才不会覆盖后面的数据。如果你从pos位置往后遍历，把前面的覆盖了，数据就乱了，这是我第一次写时翻车的点。参数上，MAXSIZE用100是个很保守的值，实验场景的数据量一般就几十条，不会有溢出风险。如果你要在报告里做性能对比，就把这个宏改大，比如100000，然后分别用顺序表和链表插入到头部，统计耗时差。

2.2 栈和队列实验：用“迷宫求解”把抽象结构变成看得见的过程

栈和队列这对兄弟，光看书上的概念会觉得很简单，但真正动手做实验就会意识到一个核心问题：什么时候用栈、什么时候用队列，教科书不会告诉你，得靠场景判断。最经典的实验是迷宫求解，用栈实现深度优先搜索（DFS），用队列实现广度优先搜索（BFS），迷宫本身用二维数组表示，1是墙，0是通路。

这个实验的代码量比线性表大，但核心就一个函数：路径搜索。我用栈写的DFS版本长这样：

#define ROW 10 #define COL 10 typedef struct { int x, y; int dir; // 记录当前探索方向，0上 1右 2下 3左 } Box; typedef struct { Box data[100]; int top; } Stack; int maze[ROW][COL] = { {1,1,1,1,1,1,1,1,1,1}, {1,0,0,1,0,0,0,1,0,1}, // ... 其余行省略 {1,1,1,1,1,1,1,1,1,1} }; int findPath(int startX, int startY, int endX, int endY) { Stack s; s.top = -1; Box current = {startX, startY, 0}; maze[startX][startY] = 2; // 标记已走过 s.data[++s.top] = current; while (s.top != -1) { Box *p = &s.data[s.top]; if (p->x == endX && p->y == endY) return 1; // 到达出口 // 按方向依次尝试，找到一个能走的就入栈 int found = 0; int nextX = p->x, nextY = p->y; switch (p->dir) { case 0: nextX = p->x - 1; break; case 1: nextY = p->y + 1; break; case 2: nextX = p->x + 1; break; case 3: nextY = p->y - 1; break; } p->dir++; // 下次尝试下一个方向 if (nextX >= 0 && nextX < ROW && nextY >= 0 && nextY < COL && maze[nextX][nextY] == 0) { Box next = {nextX, nextY, 0}; maze[nextX][nextY] = 2; s.data[++s.top] = next; found = 1; } if (!found) { s.top--; // 四个方向都试过，回溯 } } return 0; }

这段代码的核心是dir字段。它代表当前格子已经尝试到哪个方向了，这样回溯时才有记忆，不会重复走同一条死路。如果你不记dir，回溯就会变成死循环——这是迷宫实验最容易出现的bug。另外，maze数组里用2标记走过，是为了避免走回头路，但也会带来一个问题：如果一条路走不通后退回来，这条路已经被标记成2了，另一条路想经过它也不行。在很多实现里这是可接受的，因为迷宫路径通常不交叉。但如果你做的迷宫允许交叉，就得用visited数组单独标记，不修改maze本身。

在实验报告里，我会把DFS和BFS结果放在一起贴图，然后用两句话点出区别：DFS找到的路径“最先找到出口”，但不一定是最短路径；BFS找到的路径“路径最短”，因为它是按层扩展的。

2.3 树和图实验：把“数据结构”这门课变成能画出来的东西

树和图是数据结构的两个大头，也是实验报告里最厚实的部分。树的实验一般有三种选择：二叉树遍历（前中后序递归与非递归）、哈夫曼树编码、二叉排序树。图的实验则集中在邻接矩阵/邻接表的存储、DFS/BFS遍历、以及Dijkstra最短路。

我建议树的实验选“哈夫曼树”，图的实验选“Dijkstra最短路径”。为什么？因为这两个实验结论性强，报告里的“结果分析”有实实在在可以写的内容——哈夫曼树能给出编码表和平均码长，Dijkstra能给出每一轮dist数组的变化过程，这些都是表格可以展示的素材，比单纯输出一棵树的遍历序列更有说服力。

哈夫曼树的核心代码是构建过程，用优先队列（最小堆）实现最方便。在C语言里，没有现成的priority_queue，需要自己维护一个数组并每次找两个最小的权值。代码骨架如下：

#include <stdio.h> #include <string.h> #define N 8 // 叶子节点个数 #define M 2*N-1 // 最终哈夫曼树节点总数 typedef struct { int weight; int parent, lchild, rchild; } HTNode; void createHuffmanTree(HTNode huffTree[], int weights[], int n) { // 初始化：每个节点都没有双亲和孩子 for (int i = 0; i < M; i++) { huffTree[i].weight = 0; huffTree[i].parent = -1; huffTree[i].lchild = -1; huffTree[i].rchild = -1; } // 把叶子节点权值填进去 for (int i = 0; i < n; i++) { huffTree[i].weight = weights[i]; } // 核心：做 n-1 次合并 for (int i = n; i < M; i++) { int min1 = -1, min2 = -1; // 两个最小权值的下标 // 第一轮循环：在所有无双亲节点中找最小的两个 for (int j = 0; j < i; j++) { if (huffTree[j].parent == -1) { if (min1 == -1 || huffTree[j].weight < huffTree[min1].weight) { min1 = j; } } } // 把第一个最小值标记为已有双亲，再找第二个 huffTree[min1].parent = i; for (int j = 0; j < i; j++) { if (huffTree[j].parent == -1) { if (min2 == -1 || huffTree[j].weight < huffTree[min2].weight) { min2 = j; } } } huffTree[min2].parent = i; // 合并：新节点的权值是两者之和，左右孩子分别指向min1和min2 huffTree[i].lchild = min1; huffTree[i].rchild = min2; huffTree[i].weight = huffTree[min1].weight + huffTree[min2].weight; } }

这段代码里有一个非常隐蔽的细节：找min2之前必须先设置huffTree[min1].parent = i，否则min1会被再次选中，那么两个最小值就重复了。我在第一次写这个实验时没注意到这一点，结果合并出来的树总是少一层，编码也总是错。这个是哈夫曼实验里最经典的坑之一，报告里如果你能把这个问题写进“调试分析”，老师会给你加分，因为这证明你不是抄的。

Dijkstra算法我不在这里展开全部代码，只说一个参数层面的关键点：初始化时dist数组要把起点设为0，其余设为无穷大，用一个大数如9999表示。在调试时，建议在每一轮外层循环结束后打印dist和visited数组，这样你能在实验报告里贴出每一轮的中间结果——这正好是报告评分标准里“过程记录”要的东西。

3. 一分工整的实验报告怎么写：排版骨架和评分点拆解

代码写完只是第一步，实验报告的评分很大程度取决于排版和结构化程度。我见过太多人代码写得不错，但实验报告就是一堆代码截图拼起来，连标签都没有，最后只拿了个及格分。东北大学这类课的实验报告一般要求包含：封面、实验目的、问题描述、需求分析、概要设计、详细设计、调试分析、测试结果、总结。这几部分不是等权的，评分的权重分配大概是这样：

3.1 问题描述和需求分析：用一段话讲清楚“要做一个什么、用什么数据”

问题描述和需求分析是两回事。很多学生把这两个写成一回事，都是“实现一个学生信息管理系统”，然后就没有了。正确的写法是：问题描述写“题目是什么”，需求分析写“这个系统需要哪些功能、输入什么格式、输出什么格式、数据规模多大”。

我一般会这样写需求分析：

• 功能需求：实现学生信息的插入、删除、按学号查找、打印全部记录，共4个操作
• 输入规格：学号为6位整数，姓名为不超过10字符的字符串，以-1作为终止输入标记
• 输出规格：插入成功后提示“插入成功”，删除成功输出被删除的完整信息，查找成功输出匹配记录，未找到输出“未找到”
• 数据规模：测试数据不超过100条，但设计时按1000条考虑，验证插入效率

这一段的价值在于，它逼着你想清楚“边界在哪里”。比如输入学号是负数时怎么办，姓名超长时怎么办。这些边界问题你在代码里不处理，测试时必翻车。把需求分析写在代码之前，本质上是让你先想后写。

3.2 概要设计和详细设计：用图说话，别写满页文字

概要设计要画出模块结构图，详细设计要给出核心函数的调用关系和伪代码。很多人在实验报告里大段大段地贴代码，这是低效的。正确的做法是：详细设计里写清楚“这个函数做什么、输入什么、返回什么、和谁调用谁”，核心代码放到附录或者测试结果前面单独给。

以下是我常用的函数设计表格式写法，能省不少篇幅，老师看着也清楚：

这张表写完之后，代码和报告的关系就清楚了。老师一眼就能看出你掌握了哪些基本操作，而不是你的排版能力。

详细设计部分，用文字描述核心算法的逻辑即可，不用整段贴代码。比如顺序表插入：“先从表尾开始，将第length个数据元素到第pos个数据元素逐个向后移动一个位置，然后将新元素写入下标pos-1的位置，最后表长加1。移动顺序必须从后往前，否则会覆盖未移动的数据。”——这段描述比贴上完整代码更能体现你懂不懂算法本尊。

3.3 调试分析和测试结果：这才是给报告的关键部位，也是大多数人的死角

调试分析和测试结果，是一份实验报告里把分数拉开差距的地方。调试分析要求你记录“调试过程中遇到的问题、原因、以及怎么解决的”。大多数人这里写“无问题”，或者在测试结果里贴一张正常的运行截图就完事，这是巨大的浪费。

正确的做法是：把你写代码时真正遇到的报错和异常写进去。比如我在做链表实验时遇到过一个经典的野指针问题：删除节点后没有把上一个节点的next指向被删节点的后继，导致遍历时访问了已经free掉的内存。这个在调试分析里就是一个很好的素材，我会这样写：

现象：删除一个节点后，再次遍历链表时输出乱码，甚至程序直接卡死。

原因：删除函数没有修改前置节点的next指针，后续遍历走到这里时访问了已释放的地址。

解决：在删除操作中先保存前驱节点的地址，执行prev->next = p->next后再free(p)。

测试结果也不是简单的“程序运行了，输出正常”。正确做法是给出一组有代表性的测试数据和对应输出，并说明每组数据覆盖了哪个功能点。比如排序实验，你可以这样组织测试数据：

一组好的测试数据，比十张截图都有说服力。这也是实验报告里最值得花时间的地方，因为它在验的是“你懂不懂边界条件”。

4. 排序与查找实验：用性能对比让报告里的“复杂度”活起来

排序和查找，在东北大学这类课程里通常是放在最后一个综合实验里的。这个实验的设计空间很大，常见的要求是“实现三种排序算法并比较性能”或“在有序表中实现二分查找并分析查找路径”。标题里的热词也提到“数据结构排序算法”和“数据结构408图和数组”，可见这个模块在考试中的权重不低。

4.1 三种排序怎么选：快排、归并、冒泡，用数据量说话

我的建议是不要做三种同质的排序（比如冒泡、选择、插入），那样比较结果太单调。选快排、归并、冒泡三种，因为它们在算法思想上有质的分野：冒泡是交换排序，快排是分治加交换，归并是分治加合并。实验报告里“算法思想”部分有东西可写，性能对比的数字也更有层次。

代码层面，用随机数生成器生成不同规模的数据，然后记录每种排序的耗时。这里有个关键的陷阱：快排在几乎有序的数据上性能会暴跌，退化到O(n²)。如果你想在报告里展示这个边界，可以额外构造一组“基本有序”的测试数据，让快排和归并比一比，结果会很有意思。C语言里用clock()函数就能测耗时，代码片段如下：

#include <stdio.h> #include <stdlib.h> #include <time.h> void quickSort(int arr[], int low, int high) { if (low >= high) return; int pivot = arr[low]; // 每次取第一个元素作为基准 int i = low, j = high; while (i < j) { // 从右往左找比基准小的，从左往右找比基准大的 while (i < j && arr[j] >= pivot) j--; if (i < j) arr[i++] = arr[j]; while (i < j && arr[i] <= pivot) i++; if (i < j) arr[j--] = arr[i]; } arr[i] = pivot; quickSort(arr, low, i - 1); quickSort(arr, i + 1, high); } int main() { srand((unsigned)time(NULL)); int n = 50000; int *a = (int*)malloc(n * sizeof(int)); for (int i = 0; i < n; i++) a[i] = rand() % 10000; clock_t start = clock(); quickSort(a, 0, n - 1); clock_t end = clock(); double elapsed = (double)(end - start) / CLOCKS_PER_SEC; printf("快排耗时：%.4f 秒\n", elapsed); free(a); return 0; }

这里最值得注意的参数是基准值的选择。我用的代码固定取第一个元素为基准，这在随机数据上没问题，但在已排序数据上会直接退化到O(n²)。实验中如果你想展示快排的优势，建议用“三数取中”或者随机选基准，代码稍加修改即可。在实验报告的性能对比表里，这个细节要写清楚：我用的基准选择策略是什么，这样可以解释为什么快排不如某次教材上写的那么快，避免实验结果的误解。

4.2 二分查找的“路径记录”：验证查找过程比验证结果更重要

二分查找的代码简单，大多数学生十分钟就能写好，但实验报告的深度差别很大。有人写完就贴输出，有人会把每次比较的mid下标记录下来，画出一棵二分查找判定树。我在报告里更倾向于后者——因为这才是“查找”实验的核心价值：让查找路径可视化。

代码上，我一般会加一个全局数组来记录每次比较的下标，然后在查找结束后打印出来：

int searchPath[100]; // 记录二分查找过程中每次比较的下标 int pathLen = 0; int binarySearch(int arr[], int low, int high, int key) { while (low <= high) { int mid = (low + high) / 2; searchPath[pathLen++] = mid; // 记录本次比较的位置 if (arr[mid] == key) { return mid; } else if (arr[mid] > key) { high = mid - 1; } else { low = mid + 1; } } return -1; }

在实验报告里，我会用一张表把查找过程展开：比较次数、mid下标、对应值、与key的大小关系。这个表比单纯输出“找到了，下标是5”要有说服力得多。而且它直接呼应了教材上的“查找成功/失败的判定树”理论，老师一看就知道你真的理解二分查找不是“打开一个数组从中间试”，而是“每一步都在把搜索区间砍半”。

4.3 性能对比的表格模板：直接抄进报告里，改数字就行

排序实验最让人头疼的是测试报告怎么写。我提供一个我常用的模板，三列数据就能说清楚问题：

这组数据是我印象中的典型量级，不是某台机器的真实结果，但比例关系是对的：冒泡在10万规模时已经跑到几十秒，快排和归并还在零点几秒的量级。你在自己机器上跑出来的数字可能不同，但“冒泡增长速率远高于快排”的趋势是稳定复现的。实验报告里，比数字更重要的是那句分析：“当数据规模扩大100倍时，冒泡排序的耗时约扩大100倍，符合O(n²)的预期增长；快排和归并的耗时约扩大10倍，符合O(nlogn)的预期增长。”这句话写出来，整个实验的结论就立住了。

5. 实验报告避坑指南：5个现象、原因和解决路径

这一节说几个我做实验报告时踩过的坑，以及帮别人看报告时频繁发现的共性问题。每一条都是按“现象 → 原因 → 解决”的思路写的，你可以对照自己手头的报告排查。

5.1 内存泄漏：程序运行时间一长，内存就爆了

现象：链表实验里，我连续插入、删除几万次后，任务管理器看到内存占用一直往上涨。短时间运行没问题，一跑循环测试就翻车。

原因：删除节点时只做了prev->next = p->next，没有free(p)，或者反过来free了但没改指针。前者是泄漏，后者是悬空指针，两个都会出问题。

解决：删除节点时严格按照两步走，先断链后释放。另外，程序结束前遍历一整遍链表，把所有剩余节点都free掉，顺手加一个计数器，看释放的节点数是否等于插入的节点数。这个自查习惯能排查掉绝大多数内存问题。在实验报告的“调试分析”里写出这个排查过程，比写十行“程序无问题”强得多。

5.2 顺序表插入时数据被覆盖，输出全是乱码

现象：我在pos=1的位置插入一个新元素，结果原来的第一个元素没了，出现了两个相同的数据。

原因：插入操作的移动方向写反了。从前往后移动时，前面的元素会被后面的覆盖；必须从最后一个元素开始，从后往前移动。

解决：修改for循环的初始条件和方向。写代码前先想清楚：“移动方向必须是从后往前，因为前一个位置要先腾出来。”如果你在调试中遇到这个bug，在报告里写出来，这就是很好的调试素材，但别只写“已经修复”，把现象和原因写下来说明你真的排过这个雷。

5.3 二叉树的指针悬空导致层序遍历崩溃

现象：层序遍历二叉树的代码，前几次输出正常，但程序运行到某个节点后突然卡死，或者输出一个巨大的垃圾地址。

原因：构建二叉树时，某个节点的lchild或rchild没有初始化为NULL。后面的遍历用到了这个野指针，走到一个不存在的地址就崩了。

解决：构建每个节点时，把左右孩子指针用显式的NULL初始化，不要依赖malloc返回的未定义初始值。所有节点构建完毕后，可以用一个计数器统计每个节点的孩子数，加起来应该是节点总数减1，如果不等就说明指针没接对。这是一个很硬核的验证方法，实验报告里如果写出来，会被认为是真正理解树结构的人。

5.4 排序结果偶尔正确、偶尔乱序：稳定性问题没想清楚

现象：我在数组里放了一组结构体，按其中某个字段排序，结果相同关键字的记录在多次运行中顺序不一致。

原因：我用了不稳定的排序算法（比如快排）对结构体排序，比较函数只比较了关键字，没有比较其他字段。当关键字相同时，快排的交换操作会改变原有相对顺序，造成结果不稳定。

解决：两种方案。第一种，比较函数里加上次要关键字作为第二层比较条件；第二种，在结构体里加一个自增序号字段，比较函数里先比关键字、再比序号。在实验报告里，可以用几行文字说明“我选择了哪种方案，为什么”，这是一个专业度的加分项。通用做法是加序号字段，因为不需要依赖业务数据里必然存在的第二个可比较字段。

5.5 哈夫曼编码输出为空：空节点也参与了编码

现象：我写好的哈夫曼树构建代码，输出编码时有一大片空字符串或者乱码。

原因：我从数组下标1开始建树，但判断叶子节点时用huffTree[i].lchild == -1作为条件，而空节点（尚未合并的节点）lchild也是-1，于是把空节点也当成了叶子节点。

解决：判断叶子节点必须同时满足两个条件：lchild == -1 && rchild == -1。下标0是否作为存数据的起点也要统一，要么数组从0开始用，要么从1开始，别混着来。这个bug在哈夫曼实验中非常高频，几乎每届都有几个人踩中。把它写进报告里，说明你认真翻过车。

6. 让实验报告活起来：一页纸把“代码”翻译成“考点”

前面五章讲的都是“怎么写出一份合格的实验报告”，这一章我想聊一个进阶用法，也是我觉得整篇文章最值得你带走的东西：把实验报告当成考研复习资料来用。如果你现在大一或大二，正在做数据结构实验，这章的内容可能会改变你写报告的方法；如果你是为了考研在做数据结构实验，这章就是为你量身定做的。

6.1 在代码旁边做“考点标注”，把实验报告变成复习笔记

我所说的考点标注不是指在报告里加批注——排版上会很乱——而是指在一个文件里，把代码、注释和考点映射起来。比如在快速排序的代码旁边，我会写：“快排不稳定，空间复杂度O(logn)，平均时间O(nlogn)，最坏O(n²)，最坏发生在基准选择不合理时；408真题常考‘一趟排序后的结果’。”这些标注让代码的意义从“能跑”变成“能考”。

具体做法：在实验报告的最后附一页“考点对照表”，左边是实验内容，右边是对应的408考点。比如：

这张表我整整用了一年。每次做一套数据结构真题，遇到不会的题就翻回对应的实验代码，亲手跑一遍，看能不能理解为什么会这样。实验报告从“作业”变成“复习工具”的那一刻，它的价值就从10倍起步了。

6.2 血泪经验：复习数据结构时，别只刷题不写代码

数据结构这个科目有一个很奇特的规律：看起来内容不多，无非就是表、树、图、查找排序，但每次考完，总有同学在群里哀嚎说“最后一个算法大题我没写出来”。这里的问题不是刷题数量不够，而是很多人从头到尾只做选择题和简答题，没有亲手写过代码。于是考场上，面对一道让你“手写一个非递归中序遍历”的题，你能背出思路但写不出来完整代码，或者在细节处卡壳。

我的建议是，用实验报告里的代码作为基础，每天花20分钟手写一个核心算法。不用写一整个程序，就写这个函数本身。比如今天写二分查找的非递归版本，明天写快排的划分过程，后天写Dijkstra。写完后对照自己实验报告里的代码，看哪里有出入、哪里卡住了。这个习惯是考研数据结构算法大题最好的准备方式，因为你已经用自己的话写过高频代码了。

6.3 验证你的实验报告能不能“打”：三个自测问题

整份实验报告做完之后，别急着交，先把下面三个问题对着一份报告逐条自问一遍，这是我对每份实验报告做的最后一道检查：

第一，报告里的每一个代码块，我是不是能不看任何资料手写出来？如果不能，说明这段代码不是你的，交上去被老师问起来就翻车。

第二，报告里的每一张测试表和性能对比数字，我能不能解释其背后的原理？比如为什么冒泡在100000条数据时耗时是快排的几百倍，如果不能，就说明结果是抄的或者凑的。

第三，报告里的“调试分析”有没有至少三条真实的bug记录？如果没有，只能说你的代码写得太顺利，要么是你确实太强，要么是代码没写到内存操作层面，还没触发真正的坑。我倾向于相信后者。

如果这三个问题都过关，这份数据结构实验报告就不仅是一份作业，它是一份你亲手整理的数据结构复习手册。将来无论是期末考、考研，还是面试手撕算法，这几百行代码和几页调试记录，都是你最可靠的弹药库。

写实验报告这件事，我现在回头看，最深的感受是：当初认认真真调试哈夫曼树到晚上十一点的那个自己，后来在考研考场上写WPL计算题时，脑子里自动浮现出那段代码结构和debug画面，几秒钟就写出了答案。那份用心的实验报告，是我数据结构这门课没花太多力气复习却考得最好的原因。希望我的这套做法也能帮到你，让你的实验报告不只是交差那一刻的良心安慰，而是今后随取随用的真东西。

本文还有配套的精品资源，点击获取