周五下午的上机课，老师把DAY5的题目发下来时，我盯着屏幕上的链表题愣了好一会儿。东华上机DAY5这天，前四天还在跟分支循环和数组较劲，第五天直接要求逆序建链表、删除指定节点、递归求二叉树高度，难度一下从“照着课本敲”跳到了“理解后自己设计”。说实话，第一个小时我删了写写了删，差点以为是自己基础太差。等到晚上冷静下来复盘，才发现问题不在智商，而在对内存模型和调试手段的陌生。这篇文章就把东华上机DAY5这天我踩过的坑、改对的思路记录下来，给同样卡在第五天的同学做个参考。
1. DAY5为什么比前四天上了一个台阶
1.1 前四天都在练什么
多数上机课的前四天，内容通常是环境配置、变量类型、输入输出、if/switch、for/while、一维二维数组。每次上机一两个小时，大部分时间都在照着例题敲代码，把课本上的代码抄进编译器，运行通过就算完成任务。我自己的状态也是这样：第一天会把main函数拼错，第四天才勉强能独立完成冒泡排序。这个阶段的正反馈很强，因为题目足够简单，编译成功基本等于做对，就算出错，看一眼输出改个括号就能过。
但问题也藏在这四天里。因为题目简单，很多人（包括我）根本不需要理解“内存里到底发生了什么”，只要记得“数组下标从0开始”就够了。变量、数组、指针之间的关系完全是一团浆糊，只是靠着语法模板硬套。这种表面的熟练会在DAY5被一下子戳穿。
1.2 DAY5题目里出现的三个新信号
DAY5的题面明显不一样，我总结出三个信号。
第一个信号是“你不能一次写完”。前四天的题，从第一行写到最后一个大括号，中间基本是顺序结构，很少需要回头改。但到了链表、递归这类题，你没法从上到下线性地把代码写完，而是先想清楚“函数该返回什么”“指针应该怎么串起来”，再动手。比如“删除链表中的特定元素”这种题，不是把if和for拼起来就行，得想清楚两个节点之间的指针关系。
第二个信号是输入描述变长、变复杂。以前是“输入一个n，然后输入n个数”，DAY5变成了“第一行给出节点个数n，第二行给出n个节点的值，第三行给出待删除元素”。数据格式一变，处理边界条件的方式也得跟着变，读入不再是简单的scanf循环。
第三个信号是题面要求你写多个函数，而不是把所有代码塞进main。这意味着你要用函数参数传递数据，要理解指针作为参数的本质，而这恰恰是前四天最容易糊弄过去的内容。
1.3 心态崩塌的根源不是题目难，而是输出格式没适应
我一度觉得自己没救了，因为同一道题班里总有人二十分钟写完，我却卡了一个小时。后来发现，崩溃的点主要不在于算法本身，而在于调试方式没有升级。
前四天上机，错了就看输出，改一下再运行，最多加几个printf。到了DAY5，程序出错的表现变成“运行超时”或“段错误”。运行超时你根本不知道卡在哪个循环，段错误更是直接退出，连个像样的报错都没有。这时如果还用以前那套“瞎改试试”的方法，效率极低，心态自然崩。
所以DAY5真正要补的课，不是某个算法，而是“如何调试看不懂的程序”。想通这一点后，我的上机状态才慢慢恢复正常。
2. 数组与指针的边界问题：上机题最爱埋雷的地方
2.1 数组越界为什么在OJ里能通过却在本地崩溃
DAY5的题目几乎都绕不开数组，而数组最容易踩的坑就是越界。先解释一下为什么越界有时候不报错。在C语言里，数组名本质上是一个地址，数组越界访问并不会像Java或者Python那样抛异常，它只是访问了一块你没有申请的内存。如果这块内存恰好还在你的进程地址空间内、并且没有被用作关键数据，那么程序就继续运行，表现成“编译通过、结果碰巧对”。
但如果在OJ的评测环境里，内存布局和本地不一致，越界写可能踩到别的变量、返回地址或者堆管理信息，结果就是运行出错，或者输出一个谁也看不懂的数。
我自己写过一个经典错误：
#include <stdio.h> int main() { int a[5] = {0}; for (int i = 0; i <= 5; i++) { a[i] = i; } for (int i = 0; i < 5; i++) { printf("%d ", a[i]); } return 0; }这个循环里i从0到5，最后一次会写a[5]。这个位置在数组之外，本地跑可能没事，但在OJ上就是段错误。最坑的是，这种错误还不是稳定复现的，换个编译器、换个系统，结果都不一样。
2.2 用printf定位越界的实测过程
排查这种问题，最实用的方法还是加printf，把“执行到了哪里”打出来。我当时的做法是：
#include <stdio.h> int main() { int a[5] = {0}; for (int i = 0; i <= 5; i++) { printf("debug: i=%d\n", i); a[i] = i; } return 0; }如果程序崩溃，屏幕上会显示最后打印出来的i值。假如输出到i=5之后才崩，那就说明问题出在a[5]这次写入。这个方法看着土，但在上机环境里比任何调试器都管用，因为很多OJ的在线环境根本不给你交互式调试。
类似的场景还有字符串处理。比如定义char s[10]，然后读入一个长度超过10的字符串，用strcpy拷贝进去，本地可能碰巧没事，一旦在别的机器上跑就出事。排查思路完全一样：在strcpy前后分别打印缓冲区长度、当前字符串长度，很快就能定位到问题。
2.3 边界值的自测方法
DAY5之后我养成了一个习惯：写数组题时先把边界条件列出来，再写代码。
- 数组长度为0，能不能处理。
- 数组长度为1，循环是否起止正确。
- 长度上限，比如n=100000，空间开没开够。
- 循环边界用
< N还是<= N，在草稿纸上先写一遍。
另外，开数组时宁可多开几个元素，不要精打细算。比如题目说n不超过1000，我就开a[1005]而不是a[1000]。多出的几个空间能兜住各种差一错误，这是很多竞赛选手的常规操作，不只适用于上机。
3. 链表操作：DAY5的核心战场
3.1 头插法和尾插法哪个更省心
DAY5的链表题，最常见的一类就是“按输入顺序建立链表，然后做增删改查”。建链表有两种经典写法：头插法和尾插法。
头插法胜在代码短，适合题目要求“逆序输出”的情况。每次把新节点插到head前面，不需要维护尾指针：
struct node* head = NULL; int x; while (scanf("%d", &x) != EOF) { struct node* p = (struct node*)malloc(sizeof(struct node)); p->data = x; p->next = head; head = p; }尾插法更符合直观顺序，适合题目要求“按输入顺序输出”的情况。但需要维护一个tail指针，并且在处理空链表时要特别小心：
struct node *head = NULL, *tail = NULL; int x; while (scanf("%d", &x) != EOF) { struct node* p = (struct node*)malloc(sizeof(struct node)); p->data = x; p->next = NULL; if (tail == NULL) { head = tail = p; } else { tail->next = p; tail = p; } }很多新手（包括我）在尾插法里会漏掉tail->next = p这一句，结果链表串不起来。还有个容易错的地方是：如果链表一开始为空，head和tail都要指向新节点；如果只在tail为空时更新head，后面就会一直丢失头指针。
我的建议是，先看清楚题目要什么顺序。如果输出顺序和输入顺序相同，就老实写尾插法；如果输出要和输入相反，才用头插法。不要因为头插代码短就盲目用，后面在遍历、反转时会多绕很多弯。
3.2 删除节点时丢失头指针的经典翻车
链表删除是最容易出bug的操作，尤其是删除头节点时要更新head，删除中间节点要更新前驱节点的next。第一次做的时候，我按“直觉”写了一段代码，结果一运行就崩。
大致思路是这样的：先处理头节点，把所有等于k的头节点删掉，然后处理剩下的中间节点。这个思路本身没问题，但问题出在代码结构上。写完以后，我拿着一个全是k的链表测试，程序可以跑，但头指针不知道丢到哪里去了。
后来我才想明白，删除操作的关键不是“free那个节点”，而是“前一个节点的next要怎么变化”。画图理解最直接：
- 删除前：
prev -> cur -> next - 删除后：
prev -> next
如果把这个逻辑理清楚，代码就很固定：先保存q = cur，再把prev->next指向cur->next，最后free(q)。顺序不能乱，尤其不能先free再修改指针，否则你读到的next已经是野指针了。
更隐蔽的坑是，删除节点时，cur指针要不要移动。如果用cur = cur->next，那删完之后cur应该保持不变，因为新的cur已经是原来的cur->next。如果删除后还执行cur = cur->next，就会跳过一个节点没检查。这个细节我上机时至少错过两次。
3.3 哨兵节点的实战用法
为了彻底解决“头节点要不要单独处理”的麻烦，DAY5之后我开始使用哨兵节点。所谓哨兵节点，就是在真正的链表头前面加一个不存有效数据的节点，让头节点变成和其他节点一样的中间节点。
删除所有值为k的节点的代码可以这样写：
struct node dummy; dummy.next = head; struct node *prev = &dummy; struct node *cur = head; while (cur) { if (cur->data == k) { prev->next = cur->next; free(cur); cur = prev->next; } else { prev = cur; cur = cur->next; } } head = dummy.next;这样做的好处是，不需要判断“当前节点是不是头节点”，因为头节点的前驱变成了dummy。删除头节点时，prev->next同样自动更新成新头，代码结构一下就统一了。
我后来在二叉树、双向链表的操作里也用了类似的思路，都大大减少了边界判断。上机考试时，这种写法比临场分情况讨论稳得多。
4. 递归和栈溢出的那点事
4.1 递归版本很快就写出来，但卡在了哪里
DAY5的递归题，让我印象最深的是反转链表。刚看到题目时我觉得“翻转嘛，简单”，但递归版本写出来之后，自己完全看不懂。
struct node* reverse(struct node* head) { if (head == NULL || head->next == NULL) { return head; } struct node* newHead = reverse(head->next); head->next->next = head; head->next = NULL; return newHead; }这段代码只有四行核心逻辑，但第一次写对的人很少。我当时的困惑是：reverse(head->next)返回了后半段的头，那前半段的头head到底应该接到哪里去？这里的关键在于“递归返回时，本层函数负责把自己的位置接好”。
假设链表是1 -> 2 -> 3 -> NULL。调用reverse(1)时，它会先调用reverse(2)，拿到反转后的3 -> 2 -> NULL，然后再把head->next->next（也就是2的next）指向1，让链表变成3 -> 2 -> 1 -> NULL。如果你不把这个递归过程的每一步打印出来，光靠脑子想确实容易乱。
4.2 把递归调用过程“打印出来”
递归的调试，我强烈建议用带缩进的printf。给递归函数加一个depth参数，每进入一层就多打印几个空格，这样调用路径就非常直观：
void debug_reverse(struct node* head, int depth) { if (head == NULL) { printf("%.*sNULL\n", depth * 2, ""); return; } printf("%.*shead=%d\n", depth * 2, "", head->data); debug_reverse(head->next, depth + 1); }输出大致长这样：
head=1 head=2 head=3 NULL有了这个输出，再看递归代码，每一层对应哪个节点就一目了然。这个方法不只适用于链表，二叉树遍历、迷宫搜索、分治算法都能用。我当时把反转链表的递归加了几行printf，看到“返回后head->next->next指向head”的那一刻，才算真正理解递归不是靠背模板，而是靠“层与层之间的约定”。
4.3 递归的适用边界
递归虽然写起来短，但并不是所有场景都适合。上机题的数据规模往往会告诉你n的范围。如果n是十万级，递归深度大概率会超过系统栈的承受能力，出现栈溢出。C语言默认的栈空间通常在几MB到几十MB不等，每层递归还要保存局部变量、返回地址，所以深度达到上万次以后风险很高。
我自己的判断标准很简单：如果题目数据规模是10^5以上，并且递归深度可能达到这个量级，就优先用循环或者显式栈。比如二叉树的深度遍历，可以用递归，但如果是链表的递归反转，数据一大就该换迭代写法：
struct node* reverse_iterative(struct node* head) { struct node *prev = NULL, *cur = head; while (cur) { struct node* next = cur->next; cur->next = prev; prev = cur; cur = next; } return prev; }这段代码迭代版本既不担心栈溢出，也更容易调试。RAY5之后我做题的原则是：递归能用但可能爆栈时，宁可多写几行迭代代码。
5. 文件读写与输出格式：最容易丢分的隐性坑
5.1 为什么练习题要从文件读数据
上机题本身根本没要求你写文件操作，但你调试时最好借助文件。原因很简单：OJ的评测程序会把你的stdin重定向成输入文件，把stdout重定向成输出文件。你写的scanf和printf照常工作，差别只在于数据不是来自键盘，而是来自文件。
如果数据量小，手动输入没问题；数据一旦上了几十行，手动输入不仅累，还容易输错。比如链表题的输入可能是几千个节点的值，靠手敲简直不可能。所以在本地调试时，我通常会用freopen把输入重定向到文件：
freopen("input.txt", "r", stdin);这个函数会把后续的scanf全部改为从input.txt读取。提交到OJ之前记得删掉，否则程序会去找本地文件。
5.2 用命令行重定向避免反复粘贴
除了freopen，更优雅的方式是命令行重定向。假设编译出可执行文件day5，然后准备几个测试文件：
test1.txt：正常数据test2.txt：空链表test3.txt：只有一个节点test4.txt：大量数据
运行命令：
./day5 < test1.txt > out1.txt这会把input.txt的内容作为程序输入，并把程序输出保存到out1.txt。测试完第一组，再换test2跑一遍，全程不需要手动粘贴。Windows的命令行下也是一样的写法，把./day5换成day5.exe即可。
还有一个非常容易被忽视的点：调试信息不要混进stdout。用printf打印调试信息时，OJ可能会把它当成答案的一部分，直接判错。正确做法是把调试信息写到stderr：
fprintf(stderr, "debug: cur->data=%d\n", cur->data);OJ只检查stdout，stderr的内容不参与判题，本地也能正常显示。这个习惯帮我避免了很多“本地对、OJ错”的诡异情况。
5.3 多了一个空格都算错的大教训
DAY5那天我遇到过一道题，逻辑完全正确，样例也过了，但提交就是“格式错误”。后来才发现，问题出在我遍历链表输出时最后多打了一个空格。
错误写法：
while (p) { printf("%d ", p->data); p = p->next; } printf("\n");如果链表是1 2 3，输出是1 2 3，最后多了一个空格。OJ要求数字之间用单个空格分割，末尾不能有空格。我改成这样：
if (head) { printf("%d", head->data); for (p = head->next; p; p = p->next) { printf(" %d", p->data); } } printf("\n");先输出第一个节点，之后每个节点前面加一个空格，末尾正好没有多余空格。这个细节特别适合用文件重定向对比测试：把本地输出文件打开，看一眼行尾有没有空格，一目了然。
6. 下机前的最后检查项
6.1 我在DAY5踩过的最有价值的坑
大学上机课和平时自己写着玩最大的区别是：没有参考答案倒是其次，最重要的是你必须在规定时间里完成一套完整流程——读题、设计、编码、调试、交题。DAY5让我最受益的，不是学懂了链表和递归，而是意识到“运行不报错不等于结果正确”。
以前我总以为编译通过就万事大吉，现在我会花五分钟构造几组边界数据：
- 空链表
- 只有一个节点
- 删除头节点
- 删除所有节点
- 输入数据恰好达到题目上限
这些用例很多不花时间，但能拦住绝大多数隐藏bug。DAY5那道链表题，如果不是提前测了“删除全部节点”的情况，我大概率会挂。
6.2 拷贝代码改名备份的习惯
上机调试时最容易遇到的情况是：改着改着，把一个曾经能过样例的版本改坏了，想回退却回不去。DAY5那天我不只一次在崩溃后仰望天花板。
后来我学到一个非常土但极其可靠的办法：每一版代码都在文件名里留个标记。比如：
day5_linklist_v1.cday5_linklist_v2.cday5_linklist_backup_1600.c
改动大之前，先复制一份再动手。这样就算新方案全错，也能退回到上一个稳定版本。上机时如果用U盘或者网盘同步，每次提交前再备份一次，代码丢失这种事故基本上不会发生。
6.3 给DAY6留一份“手写注释”而不是“参考答案”
老师发的参考答案确实可以抄，但抄完你的收获非常有限。DAY5下机之后，我趁着思路还热，把每一道题的代码都补了详细注释。不是那种“定义变量”的废话注释，而是写下当时我犯过错的点：
// 这里用哨兵节点，是为了统一头节点和其他节点的删除逻辑 // 删除后cur要保持在原位置，否则会跳过一个节点做完这一步，第二天再打开代码，我能立刻回到当时的状态。这个习惯比多刷几道题管用得多，因为上机课真正的成长时刻，往往发生在“第二次看懂自己代码”的时候。
