数据结构课程设计实战：飞机票、Trie树、交通咨询与搜索引擎系统解析

简介：数据结构是计算机科学的核心基础，贯穿线性表、树形结构、图论算法与检索排序等知识体系。Trie树和后缀树作为高效的字符串匹配结构，支撑着搜索引擎的自动补全与子串查找；图论中的Dijkstra与Floyd算法则解决了交通咨询系统中的最短路径规划问题。飞机票管理系统通过链表与文件操作实现数据持久化，简单搜索引擎借助哈希表、倒排索引与分词技术完成信息检索。这些经典课设项目不仅覆盖了数据结构的主要考点，更将抽象理论与工程实践紧密结合。无论你是应对期末课程设计，还是希望夯实算法基础，掌握这些系统的设计思路与核心代码实现，都能显著提升问题建模与编码能力。从航班管理到文本检索，从路径优化到智能提示，数据结构的价值在实际系统中无处不在。 如果你正对着“数据结构期末课程设计”这几个字发愁，又刚好拿到了这份标题里包含飞机票管理系统、Trie树和后缀树、交通咨询系统、简单搜索引擎的资源包，那这篇文章就是写给你的。我先说结论：这套课程设计选题组合非常经典，几乎覆盖了数据结构课程里最重要的几大板块——线性表、树形结构、图论算法、排序检索和文件操作。把它们逐个啃下来，你不仅能顺利交差，还能把大学四年最抽象的一门课真正串成体系。

这篇文章我会把这四个项目全部拆开，从“老师到底想考什么”讲到“每一行核心代码为什么这么写”，再到实操阶段的步骤和坑。无论你是刚开始动手的新手，还是想给课设加分的进阶选手，都能从中找到直接能用的东西。

1. 课程设计的整体思路与考点拆解

先说点实在的：期末课程设计的评分标准，通常不是看你的系统有多炫，而是看你能不能把课上讲过的数据结构用到合理的地方。这份资源包里的四个项目，刚好分别对应了几种典型的数据结构应用场景。

1.1 四个项目分别考察什么

飞机票管理系统，本质上是线性表和文件操作的组合应用。你需要用链表或数组维护航班信息和乘客订票记录，涉及增删改查、排序、查找。这个项目考察的是最基础也最容易被忽视的能力——把业务逻辑转化成数据结构操作。

Trie树和后缀树的应用，考察的是树形结构在字符串处理中的威力。Trie树解决的是“前缀匹配”，后缀树解决的是“子串查找”。这两个结构在搜索引擎、文本编辑器、基因序列比对里都有真实应用，也是面试题里的常客。

交通咨询系统设计，核心是图论。最短路径算法（Dijkstra、Floyd）是绝对的主角。你需要把城市、公路、距离、费用这些现实问题抽象成带权图，然后让程序帮你算出“从A到B怎么走最省钱、最省时”。这个项目考察的是图的实际建模能力和算法实现能力。

简单搜索引擎，是一个综合项目。它把分词、字典树、哈希表、倒排索引、排序算法全部揉在了一起。这个项目最接近真实工业场景，做好了可以在答辩时讲出很多亮点。

1.2 学习顺序与项目难度评估

我给这套项目排一个推荐完成顺序：飞机票管理系统 → Trie树和后缀树 → 交通咨询系统 → 简单搜索引擎。

飞机票项目最简单，适合先练手，把链表、文件读写这些基本功拾起来。Trie树和后缀树是算法难度比较高的部分，需要你静下心去理解指针和递归。交通咨询系统是算法逻辑最直观的项目，图论比树好理解，因为它的应用场景太贴近生活了。搜索引模块这模块工程量最大，但前期基础打好了，它其实就是前面所有知识的组合。

难度评估表可以参考下面这个：

这个顺序也是我实际做下来的体感：从线性到树形再到图形，最后综合，知识是一层一层叠上去的。直接上来做搜索引擎，因为图算法、树结构都不熟，很容易卡壳卡到怀疑人生。

2. 飞机票管理系统：线性表和文件持久化的实战

飞机票管理系统看起来简单，但它是一道非常典型的“课设送分题”。为什么这么说？因为它用到的知识点全是最基础的——链表操作、结构体、文件读写、排序查找。但送分不代表可以随便写，老师恰恰是通过这种看似简单的项目，去考察你的代码规范度和工程组织能力。

2.1 系统结构：双链表还是单链表

我建议航班信息用带头结点的单链表存储，订票信息用双链表存储。为什么呢？因为航班信息主要是按航班号遍历查询，单链表足够；但乘客订票经常需要“退票”操作，双链表删除节点更高效——找到节点后，前驱指针直接改指向，不需要再从头遍历一遍找前驱。

航班节点的结构体可以这样定义：

typedef struct Flight { char flightNo[10]; // 航班号，如 CA1837 char startCity[20]; // 起飞城市 char endCity[20]; // 到达城市 char startTime[6]; // 起飞时间 HHMM char endTime[6]; // 到达时间 HHMM int totalSeats; // 总座位数 int soldSeats; // 已售座位数 float price; // 票价 struct Flight *next; } Flight;

这里有个容易被忽视的细节：时间类型不建议用整型存，比如“0850”作为整型存进去会变成850，后续输出还要补零。直接用字符串，既方便比较（字符串比较函数按字典序即可，前提是格式统一为HHMM），又方便显示。

比较航班时间的时候，注意字符串比较的前提是格式一致，HHMM格式下"0850" < "1230"是成立的，因为字符逐位比较时'0'<'1'。

乘客信息建议单独建一个链表：

typedef struct Passenger { char name[20]; char id[20]; // 身份证号 char flightNo[10]; // 所订航班号 struct Passenger *prev; struct Passenger *next; } Passenger;

这样设计的好处是航班和乘客解耦。订票时，在Flight链表中找到目标航班，座位数加一；同时在Passenger链表中插入一条记录。退票时反过来。

2.2 核心操作的边界条件测试

操作逻辑并不复杂，但要拿高分，必须把边界条件处理到位。我整理了几个特别容易出bug的场景：

• 订票时航班已满员：需要在订票前判断soldSeats == totalSeats，并给用户明确提示，而不是让程序崩溃。
• 退票时乘客不存在：得先查找，找到再删除。查不到就提示“无此乘客”，不能照删。
• 查询航班时按航线筛选：比如用户输入“北京到上海”，程序应该能输出所有符合条件的航班，哪怕航班的起降城市顺序写反了。
• 排序时按价格升序：如果两条记录价格相同，要有稳定排序逻辑。建议用冒泡或插入排序，最好在价格相同时按航班号再排一次，保证输出结果可预期。

文件持久化是另一个重点。程序启动时从文件读入航班数据，退出前把内存中的数据写回文件。这里我吃过一个亏：只写了保存函数，但忘记在用户选择“退出系统”时调用它，结果客户订的票，程序一关就全没了。后来我做的方案是每次数据变更后立即写回文件，这样即使程序异常崩溃，数据也不会丢太多。

2.3 排序和查找：不止一种实现

排序和查找是课设报告里要重点写的部分。飞机票系统的常用操作有三个：

• 按航班号精确查询：这个用顺序查找或折半查找都可以。如果航班数据按航班号有序存储，折半查找效率更高。
• 按起飞时间排序输出：这是典型的链表排序。单链表用插入排序比较直观，双链表可以用冒泡排序（通过交换节点的Data部分，不需要动指针）。
• 按价格筛选：最简单的遍历加条件判断。

我建议你至少实现两种排序、两种查找，并在报告里对比它们的平均时间复杂度和最坏情况。比如：

这份对比表往报告里一放，老师看到的就不只是一个能跑的程序，而是你对算法有思考。分数自然就不一样。

3. Trie树和后缀树：字符串匹配的两种高效解法

这个项目通常是课程设计里最让新手头疼的部分。因为它涉及大量指针操作和递归思想，调试起来也很折磨。但反过来，它也是最能体现你“算法功底”的项目。我一个个讲清楚。

3.1 Trie树：从自动补全到拼写检查

Trie树也叫字典树，核心思想是把一组字符串拆成字符，按前缀共享的规则组织成一棵树。比如插入“apple”和“apply”，前三个字符“app”的路径是共享的，从第四个字符开始分叉。

Trie树节点只需要两个成员：一个指向子节点的指针数组，一个标记位（表示从根到当前节点是否构成一个完整单词）。

#define ALPHABET_SIZE 26 typedef struct TrieNode { struct TrieNode *children[ALPHABET_SIZE]; int isEndOfWord; // 0表示非单词结尾，非0表示单词结尾 int count; // 记录该前缀出现的次数，可选 } TrieNode;

构建过程不复杂，核心就三步：从根开始，对单词的每个字符，看对应子节点是否存在，不存在就创建；走到单词末尾时标记isEndOfWord；重复插入相同单词时，count递增即可。

Trie树最常见的应用是前缀搜索。给定一个前缀 "ca"，你想找出所有以 "ca" 开头的单词，可以这样做：

1. 从根节点出发，按字符走完前缀路径。如果中途节点不存在，说明没有匹配单词。
2. 到前缀末尾节点后，以该节点为根做一次DFS，把所有 isEndOfWord 为真的分支路径组合起来。

这就是搜索引擎搜索框里“自动补全”功能的底层原理。你在淘宝里输入“手机”出现“手机壳”“手机支架”，背后就是类似的逻辑（工业界还会结合热度排序）。

代码骨架大概是这样：

void dfs(struct TrieNode *node, char *prefix, int depth) { if (node->isEndOfWord) { prefix[depth] = '\0'; printf("%s\n", prefix); } for (int i = 0; i < ALPHABET_SIZE; i++) { if (node->children[i]) { prefix[depth] = 'a' + i; dfs(node->children[i], prefix, depth + 1); } } } void printWordsWithPrefix(TrieNode *root, const char *prefix) { TrieNode *p = root; int len = strlen(prefix); for (int i = 0; i < len; i++) { int idx = prefix[i] - 'a'; if (!p->children[idx]) { printf("无匹配单词\n"); return; } p = p->children[idx]; } char buffer[100]; strcpy(buffer, prefix); dfs(p, buffer, len); }

递归思想是这里的核心难点。你要理解“从当前节点往下，把所有可能的路径走一遍”，剩下的工作就是递归函数的自然展开。

3.2 后缀树：从子串查找到文本索引

后缀树比Trie树更进阶一层。它在一个文本串的所有后缀上建立Trie树，然后做压缩（把只有一个子节点的路径合并到一条边上）。用途是解决“给定一个长文本，快速判断某个子串是否出现、出现了几次”这类问题。

建立后缀树的朴素方法是：把文本“banana”的所有后缀——banana、anana、nana、ana、na、a——逐一插入Trie树。插入完成后，查询子串“ana”时，直接从根开始匹配三个字符，如果路径存在就说明子串在文本中出现了。

朴素后缀Trie的构建复杂度是O(n^2)，对于几千字的短文本完全够用。但如果你想挑战更高难度，可以去了解Ukkonen算法，它能在线性时间O(n)内构建后缀树。课设的话，我建议用朴素版本加“压缩边”的优化就够了，完整实现Ukkonen算法容易把自己绕进去。

后缀树和Trie树的一个操作区别是：Trie树查询是“前缀匹配”，后缀树查询是“子串查找”。这个区别决定了它们应用的场景完全不同。

3.3 项目报告怎么包装这个模块

这块内容很多，报告篇幅可以长一些。建议从三个层面展开：

• 基础实现：解释Trie树和后缀树的节点结构、插入算法、查询算法，附上核心代码。
• 对比分析：用表格对比Trie树、后缀树和普通字符串暴力匹配的时间复杂度，体现你的理论深度。
• 应用扩展：写到文本编辑器里的“查找替换”功能、拼写检查工具、甚至DNA序列比对，都可以用后缀树加速。

这一部分写好了，整个课设的档次立刻上去。

4. 交通咨询系统设计：图结构建模与最短路径实战

交通咨询系统和前面几个项目完全不同，因为它要求你把抽象的地理信息“图化”。城市是顶点，公路是边，距离或费用是权重。老师想看到的是你对图这种非线性结构的理解，以及能不能写出真正可运行的图算法。

4.1 存储结构选择：邻接矩阵还是邻接表

两种方案各有适用场景，我这里给一个明确的判断标准：

• 顶点数量少（比如50个以内），边比较稠密 → 用邻接矩阵。实现简单，查询两个顶点之间是否有边，O(1)时间。
• 顶点数量多，边稀疏 → 用邻接表。节省空间，遍历某个顶点的所有邻接点更快。

课设场景下，城市数量一般不多，我用的是邻接矩阵，因为实现最短路径算法时逻辑更直白，不需要处理链表的指针跳转。

#define MAX_CITY 50 #define INF 0x3f3f3f3f typedef struct { char name[20]; // 城市名 // 可以扩展经度、纬度、人口等信息 } CityNode; typedef struct { int edge[MAX_CITY][MAX_CITY]; // 边的权值，INF表示不连通 int numCities; CityNode cities[MAX_CITY]; } Graph;

INF定义为 0x3f3f3f3f 是个小经验。这个值大约是10亿，比int最大值小一点，用它初始化邻接矩阵后，两个城市不连通时距离为INF，做加法运算时也不会超过int上限导致溢出（INF + INF = 0x7e7e7e7e，还是负数？不会，小于2^31，所以是安全的）。

4.2 Dijkstra算法单源最短路径的实现要点

Dijkstra算法是解决“从一个城市到其他所有城市的最短路径”的经典算法。核心思想是贪心：每次从未确定最短路的顶点中挑一个距离起点最近的，然后用它去松弛相邻顶点。

void dijkstra(Graph *g, int start) { int dist[MAX_CITY]; // 起点到各城市的最短距离 int visited[MAX_CITY]; // 是否已确定最短路径 int path[MAX_CITY]; // 记录路径前驱节点 for (int i = 0; i < g->numCities; i++) { dist[i] = g->edge[start][i]; visited[i] = 0; path[i] = (dist[i] < INF) ? start : -1; } dist[start] = 0; visited[start] = 1; for (int i = 0; i < g->numCities - 1; i++) { int u = -1, minDist = INF; for (int j = 0; j < g->numCities; j++) { if (!visited[j] && dist[j] < minDist) { minDist = dist[j]; u = j; } } if (u == -1) break; visited[u] = 1; for (int v = 0; v < g->numCities; v++) { if (!visited[v] && g->edge[u][v] < INF) { if (dist[u] + g->edge[u][v] < dist[v]) { dist[v] = dist[u] + g->edge[u][v]; path[v] = u; } } } } }

path数组很多人会遗漏，但它是回答“最短路径具体怎么走”的关键。比如从北京出发到广州，dist存的是距离数值，path存的是每个城市的前驱城市。回溯的时候，从广州一路往前找，就能把整条路径打印出来。

如果课设要求“既能算最短距离，又能打印路径”，path数组是必写的。

4.3 Floyd算法的多源最短路径

如果你不想只做单源最短路径，可以用Floyd算法实现“任意两个城市之间的最短路径”。它的核心是三重循环，思路极其简洁：

for (int k = 0; k < n; k++) for (int i = 0; i < n; i++) for (int j = 0; j < n; j++) if (dist[i][k] + dist[k][j] < dist[i][j]) dist[i][j] = dist[i][k] + dist[k][j];

Floyd算法的优点是好写、好理解，缺点是O(n^3)的时间复杂度。但对于课设级别的数据量（城市总数几十个），三层循环瞬间算完，完全没有性能压力。如果你在交通系统中加入了“不走重复城市”的需求，Floyd也能配合path记录做到。实际上，Floyd的path记录是一个二维数组，path[i][j]表示从i到j路径上的第一个中间节点。

Dijkstra和Floyd的对比表，放报告里加分：

4.4 交通咨询系统的功能够怎么扩展

基础版只能算最短距离，但如果想让课设出彩，可以添加这些扩展功能：

• 双重权值：每条边既存距离又存费用。用户输入“最省钱”就按费用权值跑Dijkstra；输入“最快”就按时间权值跑Dijkstra。
• 最少换乘次数：把每条边权值视为1，跑BFS，得到的就是最少换乘次数。
• 多条件组合：先筛选费用低于某个阈值的路径，再在其中选距离最短的。

这些扩展不复杂，但答辩时能体现你对问题的深入思考。建议至少实现其中两个。

5. 简单搜索引擎：把前面所有数据结构串起来

搜索引擎这个项目，是所有课设中最能拔高你代码水平的一个。因为它不是一个单一数据结构的演示，而是一个完整的信息检索系统：输入关键词，返回相关的文档列表。如果要给老师一个“综合运用能力最强”的评价，这个项目是关键。

5.1 倒排索引：搜索引擎的基石

搜索引擎最核心的数据结构是倒排索引。倒排索引本质上是“关键词 → 文档列表”的映射。

举个例子，你有三篇文档：

• doc1: “数据结构是计算机专业的核心课程”
• doc2: “算法设计与数据结构紧密相关”
• doc3: “计算机专业的学生需要学算法”

建立倒排索引后，你得到的是：

用户搜索“数据结构”，直接查表就知道是doc1和doc2。这正是搜索引擎为什么要构建倒排索引的原因——正排索引（文档→关键词）需要遍历所有文档才知道哪些文档包含关键词，而倒排索引省去了这一步。

倒排索引的底层存储可以用哈希表：键是关键词，值是一个链表或动态数组，里面存的是文档ID。查询时O(1)定位关键词，然后遍历文档列表。

5.2 中文分词怎么处理

中文和英文不一样，英文单词之间有空格天然分隔，中文没有。所以做中文搜索引擎，分词是绕不开的一步。课设级别不需要上机器学习分词器，两种简单方案足够：

• 基于词典的最大正向匹配：准备一个常用词词典，从句子开头尝试匹配最长的词。比如“数据结构是计算机专业的核心课程”，从左往右，先看“数”“数据”“数据结”……直到命中词典中最长的词“数据结构”，然后继续往后切。
• 基于n-gram：把所有相邻的两个字或三个字都作为关键词。比如“数据结构”切成“数据”“结构”“数据结”“据结构”等。这种方法实现简单，但会让索引体积膨胀，噪声也大。

我建议用最大正向匹配。实现难度适中，分词效果在课设文档集规模下完全够用。在代码里加一个词典文本文件，程序启动时加载进Trie树，这样分词查找的过程本身就是一次Trie树应用。

5.3 搜索引擎的完整流程

整个项目的流程可以拆成四个阶段：

• 阶段一：文本预处理。读取所有文档，去掉标点符号和停用词（“的”“了”“是”等无意义词），然后分词。
• 阶段二：建立倒排索引。遍历所有文档，对每个词，往哈希表的对应文档列表里加入当前文档ID，同时记录词频。
• 阶段三：查询处理。用户输入关键词，先分词，然后对每个词查找倒排索引，取多个关键词对应文档列表的交集或并集。
• 阶段四：相关性排序。按词频、位置信息给文档打分，输出排序结果。

如果用户输入多个关键词，比如“数据结构 算法”，基础做法是求两个词对应文档列表的交集（同时包含两个词的文档）；进阶做法是用TF-IDF给文档打分，按得分排序。

5.4 用Trie树优化关键词匹配

在建立倒排索引时，每个词都要插入哈希表或Trie树。我用Trie树优化了一个环节：把所有关键词按前缀组织，用户输入“数据”时，可以快速给出所有以“数据”开头的搜索建议（如“数据结构”“数据库”）。这就和第二个课设项目遥相呼应了。

代码级别，Trie树节点加一个字段vector docList，表示包含当前前缀的所有文档ID。这样在用户输入前缀时，直接沿着Trie树走到对应节点，拿到的docList就是“包含该前缀的所有文档”。这个设计在答辩时很加分，因为它展示了你对多项目知识进行串联的能力。

6. 课设实操全流程与踩坑经验

讲完四个项目的核心设计，接下来聊一聊实际动手时的工程问题。很多同学的课设代码在Dev-C++里能跑，拷到机房电脑上就崩了；或者一运行就闪退，查了半天发现是文件路径问题。这些坑我都踩过，整理如下。

6.1 开发环境与工程组织建议

语言选C还是C++？我的建议是：课设报告没特殊要求就选C++，因为可以用string、vector、fstream，比C语言手动管理char数组和文件指针省心太多。但如果老师指定了C语言（很多学校数据结构课实用C语言版），那就乖乖用C，毕竟严蔚敏老师的教材和配套PPT都是C语言版的，老师熟悉的也是C语言的实现风格。

工程组织上，不要把所有代码写进一个main.cpp。建议按模块拆分成多个文件：

- main.cpp // 菜单和流程控制 - flight.cpp/h // 飞机票管理模块 - trie.cpp/h // Trie树模块 - graph.cpp/h // 交通咨询模块 - search.cpp/h // 搜索引擎模块 - data/ // 存放文档和数据的文件夹 - flights.txt - docs/

这样做的好处有两个：一是代码结构清晰，报告里写“模块化设计”时有底气；二是调试时只需要编译改动过的文件，效率高很多。

6.2 频繁踩到的五个经典Bug

Bug 1：读取文件时缓冲区越界

用scanf("%s", flightNo)读字符串时，如果文件里某一行数据长度超过数组长度，程序直接崩溃。建议用scanf("%19s", flightNo)指定最大读入宽度，写成数组大小减一。这个问题看起来很基础，但很多同学的代码就是在运行到几十条数据时突然崩掉的。

Bug 2：链表节点删除后悬挂指针

删除节点时，如果只改了当前节点的next，没有处理前驱节点，就会出现悬挂指针。标准的做法是：双向链表删除节点要同时处理prev->next和next->prev；单向链表删除必须保存前驱节点。写完后最好用边界用例测一下：删除头节点、删除尾节点、删除中间节点。

Bug 3：Dijkstra初始化时未处理自身距离

dist[start]必须显式置为0，visited[start]置为1。不少错误的写法和上面代码骨架里一样，初始化循环里已经把dist[i] = edge[start][i]，但edge[start][start]可能不是0（初始化矩阵时写成了INF），导致自身距离无穷大，算法直接错乱。写一个初始化函数，把所有顶点到自身的距离置为0，所有不连通边置为INF，这是固定套路。

Bug 4：Trie树递归DFS时栈溢出

这个问题的触发条件是：插入的单词特别长（几百个字符），DFS递归深度很大。课设数据规模下一般不会遇到，但如果你把搜索引擎的分词词典也放进Trie树里，词典里有几千个词，Trie树深度最多几十层，完全没问题。如果真遇到长度超长的输入，可以把递归改成显式栈。

Bug 5：不同操作系统下文件路径分隔符

Windows下路径分隔符是反斜杠\，Linux/macOS下是正斜杠/。课设报告里如果用到相对路径，建议统一用正斜杠/，因为Windows的fopen函数其实兼容正斜杠。把这个习惯养成，以后你写代码会少掉很多头发。

6.3 报告答辩的加分技巧

代码写完了，课设还没结束。期末课程设计通常需要提交一份报告并参加答辩，报告的质量直接影响最终成绩。

报告结构我建议按下面这个模板来：

• 摘要：一两句话概括所有系统的功能和所用数据结构。
• 需求分析：用自然语言描述每个系统要解决什么问题。
• 概要设计：画出系统的模块划分、每个模块的职责。
• 详细设计：给出核心数据结构的定义、核心算法的流程图或描述。
• 测试与调试：贴关键测试用例的输入输出截图，说明边界情况。
• 心得体会：写你踩过的坑、解决了什么问题、学到了什么。

答辩时，有两点很重要。第一，不要照着PPT念，要准备一段“这个系统我负责了XX功能，最难的环节是XX，我通过XX解决”这样的表述。第二，一定要提前演练一遍系统操作流程，别在演示时因为数据文件路径不对，当着老师的面闪退。

7. 从课设延伸到面试和考研的进阶方向

四个课设做完，你的数据结构基础就算打牢了一大半。但如果你还有余力，我建议你做一些延伸思考，因为课设项目里用到的知识和技巧，在求职面试和考研复试里都非常能打。

7.1 数据结构知识点串联复习法

做完这个课设，你应该能回答以下几个问题了：

• 数组和链表的适用场景分别是什么？飞机票管理系统里为什么用链表而不是数组？（因为航班数量会动态变化，链表插入删除不需要移动大量元素）
• Trie树为什么能高效做前缀匹配？它和哈希表相比，优势在哪里？（哈希表不支持前缀查找；Trie树支持）
• 后缀树和Trie树是什么关系？后缀树在子串查找上的时间复杂度是多少？（O(m)，m为子串长度）
• Dijkstra算法为什么不能处理负权边？Floyd算法为什么可以检测负环？（Dijkstra的贪心策略假设已确定最短路的顶点不会再被更新；Floyd更新公式能发现dist[i][i] < 0的情况）
• 倒排索引为什么被称为“倒排”？它和正排索引的区别是什么？（正向索引：文档→词项；倒排索引：词项→文档）

这些问题在面试中属于基础题，但很多候选人答不上来。你要是能结合课设里的实际场景回答，面试官会对你刮目相看。

7.2 给后续学习者的三个建议

建议一：不要急着抄代码

拿到一个课程设计题，先画图，再写伪代码，最后才动键盘。先把数据结构和流程理清楚，代码只是翻译而已。你抄了别人的代码，可能连里面有个Bug都发现不了。

建议二：每次写完一个功能，立刻测试

不要等所有功能都写完了再统一测试，否则一旦出错，你根本不知道是哪里出的问题。每写完一个函数，给一个最小测试用例，跑通了再往下写。

建议三：保留所有版本的代码

我当年做课设时，用Git管理代码，每个功能完成后commit一次。到写报告时，我可以直接调用历史版本对比，展示我的实现历程。如果你不会Git，最简单的做法是给文件夹复制一份带日期的副本。别小看这个习惯，它会在很多时刻救你一命。

这套课程设计做完，你会发现自己看待编程的方式都不一样了。以前你写的代码可能只是“能跑”，现在你会开始关注“这段代码用的是什么数据结构、时间复杂度是多少、有没有更好的方案”。这种思维方式的转变，比课程分数本身值钱得多。

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