命令行里跑一条蛇是很多人写下的第一个有交互的程序。它不需要图形库、不需要框架、不需要打包一个源文件、一条编译命令、一个黑框框就能跑起来——但真正让它跑得顺、不闪、不卡、不出诡异 bug里面的东西远比打印几个字符要多终端光标控制、非阻塞键盘输入、帧同步、环形缓冲区、自身碰撞判定、随机落点采样。这篇就围绕控制台简易程序——贪吃蛇这个题目把我这些年在不同机器上反复重写这个 Demo 时踩过的坑和最终定型的一套写法完整拆开为什么用定长数组加双指针而不是链表、为什么必须整块刷新而不是逐字符打印、为什么方向键不能简单取反、为什么精神饱满写出来的代码一跑就闪成一片。刚入门的同学可以照着抄一份能跑的写过几版又总觉得手感不对的老手重点看第 4 章的排查部分那里基本覆盖了这个题目九成以上的翻车点。1. 整体设计与思路拆解1.1 为什么我坚持用控制台而不是图形库很多人拿到这个题目第一反应是上个图形库不香吗。香但没必要而且会偏题。控制台版本的真正价值不在于画面而在于它把游戏循环这个抽象概念剥得只剩骨头一个 while 循环里读输入、更新状态、渲染画面三件事循环往复。你在这三十行代码里理解的东西和几万行的引擎主循环是同一套逻辑只是后者把每一环都放大了几百倍。更实际的理由是可移植性。控制台程序在任何一台装有编译器的机器上都能跑连交叉编译都不需要额外依赖库一个几十 KB 的可执行文件丢过去就能用。我在给新人做代码入门演示的时候从来不用那些要配置半天的环境直接打开终端编译一下三秒钟看到结果这个正反馈很重要。还有一层是资源占用。控制台贪吃蛇的 CPU 占用几乎可以忽略内存也就是几十 KB 的字符缓冲区。这个特性在某些场景里其实是刚需——比如在没有图形界面的服务器上做个小演示或者给一个极简环境做个自检小游戏控制台版本是唯一可行的选择。所以别小看这个简易二字简易往往意味着依赖少、故障面小、可控性强。当然控制台版本也有天然的约束最典型的是刷新粒度。终端是字符设备你没法像图形接口那样只改一个像素每一次刷新至少要重写一个字符格。这就逼着你从一开始就建立整帧渲染的思维——这个思维在后面第 2 章讲双缓冲的时候还会反复提到。1.2 蛇身数据结构我为什么最后回到了环形数组新手写这个题目十有八九会先想到链表因为蛇头加一节、尾巴减一节听起来就很像链表操作。第一版我也这么写的结果发现几个问题每帧都要 malloc 和 free虽然开销可忽略但代码复杂度上去了遍历做碰撞检测的时候指针跳来跳去缓存不友好调试的时候打印一个链表还得写额外的遍历函数。所以我后来统一改成了定长数组加头尾双指针的环形结构这是我最推荐的做法。核心就三个变量一个固定大小的坐标数组一个头索引一个长度。移动的时候不需要搬数据只要把新头部的坐标写到(head 1) % CAP的位置头索引前进一步长度加一如果这一帧没吃到食物就把长度减一尾巴索引自然跟着前进。#define MAX_LEN 400 typedef struct { int x, y; } Point; static Point body[MAX_LEN]; static int head 0; /* 蛇头在数组中的下标 */ static int len 3; /* 当前长度 */ /* 取第 i 节身体的坐标i0 是头 */ static Point get_seg(int i) { return body[(head - i MAX_LEN * 2) % MAX_LEN]; }这里的MAX_LEN * 2是为了防止head - i出现负数时取模结果为负——这是 C 语言里非常经典的一个坑-3 % 10得到的是-3而不是7。我在第一次写环形缓冲区的时候就栽在这上面蛇身绘制出来只显示半截查了半小时。环形数组的好处是内存一次分配好零碎片访问是连续的缓存友好逻辑上头进尾出用两个整数就能表达不用维护任何指针关系。代价是要算好容量上限不过对于一张 20×20 的地图400 个格子就是理论最大值够用了。1.3 主循环的时间片设计别让 Sleep 决定你的手感主循环的结构看着简单while (running) { read_input(); /* 只读不改状态 */ update(); /* 根据当前方向推进一帧 */ render(); /* 整帧绘制到缓冲区并输出 */ sleep_until_next_tick(); }但这里的节奏控制是手感的关键。最粗暴的写法是Sleep(100)放循环末尾问题是 Sleep 的精度很差而且渲染耗时波动会让实际帧间隔忽长忽短玩起来就是一顿一顿的。我后来改成用累计时间做判定记录上一帧的时间戳每帧算一下距离下次逻辑推进还差多少毫秒不够就补一个短睡眠。更稳妥的做法是把逻辑刷新和输入读取解耦逻辑每 120ms 推进一格但输入每 10ms 轮询一次。这样即使你把速度调到最快按键的响应依然是即时的不会出现按了没反应走两格才开始转弯的粘滞感。这个分离在后面的实现里会用一个小技巧实现——每帧内多次轮询输入只保留最后一次有效方向。1.4 影响范围这个题目到底能练到什么从技能覆盖来说它涉及了终端 I/O、状态机、缓冲区管理、边界条件、随机数、跨平台差异六个方向。任何一个方向单拿出来都是一个独立话题而它们在这个小题目里是耦合的这正是它的教学价值所在。你在别的地方学什么是环形缓冲区可能觉得抽象但在这里缓冲区溢出的后果就是蛇头把蛇尾吃掉然后画面崩掉反馈非常直接。从可扩展性来说这个骨架能往上叠的东西很多加障碍物、加穿墙模式、加双人对战、加存档回放。而每一层扩展考验的都是同一件事——你的状态管理够不够干净。所以我一直觉得判断一个人代码组织能力如何看他写的贪吃蛇有没有把所有东西塞进 main 函数就知道了。2. 核心细节解析与实操要点2.1 终端光标定位两种流派和它们的取舍控制台要画出原地更新的效果必须能把光标挪回去。这里有两条路。第一条是 ANSI 转义序列也就是\033[行;列H这种写法配合\033[?25l隐藏光标、\033[?25h恢复光标。优点是纯文本跨平台代码里看着也干净。缺点是它在部分终端环境下需要额外开启支持——比如在较新的终端宿主里得先设置控制台的输出模式把虚拟终端处理那一位置 1否则你打印出去的转义序列会被当成普通字符原样显示屏幕上就是一串乱码。第二条是调用平台提供的控制台接口直接设置光标位置。优点是稳不依赖终端对转义序列的解析缺点是不跨平台换到别的系统就得重写。我的做法是写一层薄薄的抽象把两个平台各写一个版本上层代码只调用cursor_to(x, y)和hide_cursor()。这样主逻辑是干净的平台差异全部收敛在一个文件里。/* 平台 A 的实现片段示意 */ static void cursor_to(int x, int y) { printf(\033[%d;%dH, y, x); } static void hide_cursor(void) { printf(\033[?25l); fflush(stdout); }注意隐藏光标的指令和恢复光标的指令必须成对出现。如果你的程序在隐藏光标之后因为某种原因异常退出了终端会一直处于看不见光标的状态用户得手动敲reset才能恢复。所以稳妥的写法是注册退出处理或者干脆在每帧渲染的开头隐藏、结尾恢复。2.2 蛇身移动的本质头进尾出把移动想清楚这个题目就成了一半。蛇移动一格本质上是两个动作新的头部位置插到队首如果没有吃到食物队尾那一节消失。用环形数组实现时消失根本不需要擦除只要把长度减一那一节的坐标就自动被下次覆盖了。具体到计算新头的坐标等于当前头坐标加上方向向量。方向用(dx, dy)表示上就是(0, -1)下是(0, 1)左是(-1, 0)右是(1, 0)。这一格算出来之后先做碰撞判定然后再决定是继续推进还是直接游戏结束。static void step(int dx, int dy) { Point nh get_seg(0); nh.x dx; nh.y dy; if (hit_wall(nh) || hit_self(nh)) { running 0; return; } head (head 1) % MAX_LEN; body[head] nh; if (nh.x food.x nh.y food.y) { len; /* 吃到食物长度增加尾巴不动 */ score 10; spawn_food(); } else { /* 尾巴自动前进一格在环形数组里靠 len 控制可见范围即可 */ } }这里有个反直觉的细节长度控制才是尾巴的移动。很多人第一次写的时候会额外维护一个 tail 索引然后每次手动tail (tail 1) % CAP结果吃着吃着发现尾索引和长度不一致了画面出现幽灵蛇身。少维护一个冗余状态就少一个出错的地方。2.3 自身碰撞判定那个最容易被忽略的边界撞墙好判只要坐标越界就结束。自身碰撞有个很微妙的边界要不要把尾巴算进去。规则是这样的如果这一帧没有吃到食物尾巴会在同一帧移开那么蛇头走进原来尾巴所在的格子是合法的玩家看到的是蛇头刚好追上尾巴。但如果这一帧吃到了食物尾巴不动那么那一格就是实心的撞上去必须判定死亡。这个差异在实际代码里体现为一行的偏移量static int hit_self(Point nh) { /* 若本帧会吃到食物尾巴不动需要连尾一起检查 */ int last will_eat(nh) ? len - 1 : len - 2; for (int i 0; i last; i) { Point s get_seg(i); if (s.x nh.x s.y nh.y) return 1; } return 0; }我在第一版里没区分这个结果蛇在长度等于 4 的时候正常转个弯就会被误判死亡。当时以为是方向计算错了把方向逻辑全部打印出来看了一晚上最后才发现是这里少减了 1。这个坑几乎每个写过这个题目的人都踩过我把它放在排查表的第一条。2.4 食物落点随机数不是随便用生成食物就一句话在空格子里随机挑一个。但实现上有两种写法效果差别很大。第一种是拒绝采样随机生成坐标如果落在蛇身上就重新生成。简单但在地图快被填满的时候会有大量无效循环——最坏情况下蛇占了 350 个格子剩下 50 个空格平均要试 7 次才中一次虽然还是很快但如果地图更大、蛇更长这个概率会恶化得很明显。第二种是先收集所有空格子再从中随机选一个。开销是每次遍历一遍地图但结果稳定永远不会退化。地图是 20×20 的话遍历一次才 400 次操作完全可以接受。我现在的做法是先算出空格总数再用一次随机数定位然后从头扫到第 k 个空格。这样不需要额外的数组也不会有退化风险static void spawn_food(void) { int total W * H - len; if (total 0) { running 0; return; } /* 通关防止死循环 */ int k rand() % total; for (int y 0; y H; y) { for (int x 0; x W; x) { if (occupied(x, y)) continue; if (k-- 0) { food.x x; food.y y; return; } } } }提示total 0这个分支千万别省。少了它蛇填满整张地图时就会进死循环终端卡住用户只能强制结束进程。这是看起来不可能发生但实际测试中一定会被触发的一种边界。2.5 输入读取非阻塞是硬要求如果用常规的输入读取函数程序会在那里停住等你敲了回车才继续。游戏循环就变成了按一下动一步完全没法玩。所以必须用非阻塞读取有按键就取没按键立刻返回。不同平台的做法不一样在 Windows 上是检测按键缓冲加取字符的无回显版本在类 Unix 系统上则是把终端设为原始模式后配合非阻塞标志读取。原始模式下还要注意程序退出时必须把终端属性还原回去否则终端会处于按回车不换行的异常状态用户得手敲一个复位命令才能恢复正常。方向键在多数终端里不是单个字符而是一个转义序列所以取到第一个字符之后往往还要再取一次才能拿到真正的方向标识。这个再取一次如果写成阻塞读取一旦前面那个字符不是转义前缀程序就会卡在那里等输入。稳妥的写法是先判断首字符是不是前缀是的话再取第二个否则直接忽略。3. 实操过程与核心环节实现3.1 从零搭骨架目录、编译与第一帧我习惯的结构是两个文件一个放平台相关的底层操作一个放游戏逻辑。小 Demo 当然可以全塞一个文件但拆开之后以后换平台只需要改底层那一个。编译命令很简单gcc snake.c -o snake就够了不需要链接任何第三方库。Windows 上如果用的是某个常见的轻量编译器套件同样一条命令即可。第一步先不写蛇只写一个能框出地图、能在指定位置放一个字符的版本。这一步的目的是验证终端控制是否正常如果边框画出来是歪的、跳行的、每次刷新都滚屏那说明坐标基准或者行宽处理有问题先把这一层修好再往上加逻辑否则后面调起来会非常痛苦。#define W 20 #define H 20 static char canvas[H][W 1]; /* 1 存字符串结束符 */ static void render(void) { cursor_to(1, 1); for (int y 0; y H; y) { canvas[y][W] \0; fputs(canvas[y], stdout); fputc(\n, stdout); } fflush(stdout); }这段代码有两个要点值得展开。一是缓冲区每行多留一个字节存结束符fputs才能安全地用二是整个画面一次性输出后统一刷新缓冲而不是每打印一个字符都刷一次。这两点直接决定了画面闪不闪后面第 4 章还会细说。3.2 帧同步与速度曲线的参数计算初始速度我一般设成 120 毫秒一格这个数值是试出来的太快新手反应不过来一开局就撞墙太慢120 毫秒一格走 20 格要两秒多会觉得拖沓。100 到 150 之间是舒适区具体看地图大小地图大就偏快一点。加速逻辑我不用每吃一个加速一点这种线性叠加那样到后期会快得失控。我用的是分段封顶的做法static int tick_ms(void) { int level score / 50; /* 每 50 分升一级 */ int t 120 - level * 10; if (t 60) t 60; /* 下限 60ms不再加速 */ return t; }算一下吃到 5 个食物50 分后间隔降到 110ms吃到 25 个食物后降到 70ms吃到 30 个后触底 60ms 封顶。60ms 这个下限是我反复测试定的——再快的话在普通终端里因为字符输出的延迟抖动观感上会开始跳格玩家会误以为自己按错了方向。注意帧间隔不要直接拿固定值去休眠因为渲染本身也要时间。如果渲染耗时 15ms、你还要睡 60ms实际帧间隔就变成 75ms 了速度曲线整体会偏慢。我现在的写法是记录每帧开始的时间戳用本帧已耗时从间隔里扣掉剩下的才休眠。3.3 双缓冲闪屏问题的根治办法这是我认为整个题目里最值得单独讲的一段。最早我的渲染是这样的先把整个屏幕清空再逐行打印地图再打印蛇和食物。运行起来画面就是在疯狂地闪肉眼看着甚至有点晃眼。原因很直白清空和重绘是两个可见的过程中间那个空屏状态虽然只存在几毫秒但人眼能捕捉到。解决办法是不让中间态出现——先在内存里把整帧拼好然后一次性输出。static void draw_frame(void) { /* 第一步全部填成背景 */ for (int y 0; y H; y) for (int x 0; x W; x) canvas[y][x] ; /* 第二步画边框 */ for (int x 0; x W; x) { canvas[0][x] #; canvas[H - 1][x] #; } for (int y 0; y H; y) { canvas[y][0] #; canvas[y][W - 1] #; } /* 第三步画食物 */ canvas[food.y][food.x] *; /* 第四步画蛇头单独用不同字符 */ for (int i len - 1; i 0; i--) { Point s get_seg(i); canvas[s.y][s.x] (i 0) ? : o; } }配套的是把光标移回原点后整块输出并且在输出前后各做一次刷新控制。实测下来这套组合之后闪屏基本消失剩下的轻微抖动是终端本身字符渲染速度决定的没法再优化了。从只改变化的格子这个角度想理论上还能更进一步——只重绘差异部分。但对于 20×20 这么小的画面一次全量重绘的开销远小于计算出差异的成本纯属过度设计。我试过做差异比对帧耗时反而增加了因为要遍历比对两次。所以这个场景下全量双缓冲就是最优解别想太多。3.4 收尾环节暂停、计分与退出恢复游戏结束之后如果不做处理程序直接退出终端里会残留光标隐藏状态用户下次敲命令看不到光标体验很糟糕。我的做法是在退出路径上统一做清理恢复光标、把终端属性还原、把最终得分打印在画面下方。static void cleanup(void) { show_cursor(); reset_terminal(); } static void game_over(void) { cursor_to(1, H 2); printf(Game Over score%d len%d\n, score, len); printf(press R to restart, Q to quit\n); fflush(stdout); }暂停功能加不加都行但加一个挺有用——尤其是调试的时候能让你在某一帧停下来慢慢看位置对不对。实现上就是把主循环里的是否推进和是否渲染分开暂停时仍然读输入、仍然渲染只是跳过逻辑推进。这个改动很小但对调试效率的提升很明显。4. 常见问题与排查技巧实录4.1 画面疯狂闪烁这是最高频的问题没有之一。原因基本可以归结为两类一是每帧用了清屏命令这种先全清再重画的做法在任何终端上都必然闪二是逐字符输出每个字符都触发一次刷新调用输出缓冲被拆成了几百次小写入。排查顺序建议这样先确认渲染是不是走的内存缓冲区一次性输出如果不是改掉再确认清屏是不是每帧都调如果是改成光标归位加全量覆盖。这两步做完九成以上的闪烁会消失。剩下那一成可能是行结尾处理不当导致的滚动。如果你的地图宽度刚好等于终端宽度最后一列字符输出后终端会自动换行接着你又输出一个换行符多出来的那个换行会让整个画面往上顶一行累积几次之后画面就开始滚屏。解决办法是把地图宽度设得比终端窗口窄两格或者干脆不输出行尾换行改用光标定位到下一行行首。现象最可能的原因处理方向整屏白光闪动每帧调用清屏命令改为光标归位后整块覆盖轻微抖动逐字符输出未合并拼好缓冲区一次性写出画面逐渐上移行尾换行多余去掉多余换行用定位代替边框错位字符宽度与坐标不一致确认坐标按字符格而非像素计4.2 按上键却往下撞死这个现象看着像按键识别错了实际上九成是因为没有过滤反向输入。蛇当前向右走玩家迅速按了左如果你直接把方向赋给当前方向下一帧蛇头就会插进自己的身体判定死亡。正确做法是缓存下一个方向在推进逻辑之前统一校验如果新方向和当前方向正好相反直接丢弃这次输入。这里有个容易忽略的点——不能拿新方向和当前方向比而要拿新方向和上一帧生效的方向比。因为玩家可能在一帧之内连按两次你只保留了最后一次如果中间那次是有效的逻辑就会错乱。static void accept_dir(int ndx, int ndy) { if (ndx -dir_x ndy -dir_y) return; /* 拒绝反向 */ if (ndx 0 ndy 0) return; next_dx ndx; next_dy ndy; }还有一种情况是按键取到的是转义序列第二个字符没取干净残留字符被当成了下一次输入导致方向莫名其妙改变。排查方法很简单把每次读到的键值打印到日志里可以输出到画面的调试行看看是不是出现了预期之外的编码。4.3 食物长在蛇身上而且怎么都消不掉如果偶尔出现一次多半是随机采样没做占位检查如果是一直在同一个位置刷那可能是随机数没有播种每次运行序列都一样恰好那个位置有问题。但还有一种更隐蔽的原因吃了食物之后没有及时更新长度。逻辑上你增加了分数、生成了新食物但长度那一行忘了写于是蛇头停在食物格子上下一帧你又判定头在食物上又加一次分又生成食物。表现为分数疯涨、蛇身不增长、画面卡在那一格。我遇到过这个加了日志之后一眼就看出来同一帧里食物生成被调用了三次。排查这类问题有个通用手法在关键状态变更处打一个可开关的调试输出把帧号、蛇头坐标、长度、食物坐标一起打印出来。看着这四列数字跑十几帧异常几乎无所遁形。4.4 按键响应粘滞、方向转换不跟手典型表现是想转弯的时候按了键蛇没反应再按一次蛇连转两下直接撞墙。原因通常是把输入读取和逻辑推进绑在了同一个节奏里也就是每 120ms 才读一次键。玩家在这 120ms 内按的键如果只保留最后一次前面的都丢了如果队列缓存又会积压成一串延迟指令。我的处理办法是固定每帧多次轮询输入、只保留最后一次有效方向轮询间隔压到 10ms 左右。这样从玩家按键到画面反馈的延迟最长也就一帧手感立刻就对了。问题排查入口定论方法响应粘滞输入轮询频率打印每次读键的时间戳看间隔连转两下是否缓存了输入队列改为只保留最后一次有效方向方向丢失转义序列前缀处理记录原始键值序列逐字节比对松键后仍在走是否做了按键释放判断确认逻辑只依赖按下事件4.5 几个不太容易想到的坑第一个是蛇的自碰撞判定包含了尾巴前面第 2.3 节已经详细讲过这里只强调一句这是这个题目里最经典的 off-by-one。第二个是地图尺寸与缓冲区尺寸不一致。我见过一个版本缓冲区按 20 行分配地图却按 22 行绘制于是越界写坏了相邻的内存表现为画面右下角偶尔冒出一个随机字符。这类问题在开了越界检查的编译选项下能很快抓到所以我建议编译时把警告等级调高别嫌输出噪声多。第三个是在暂停状态下按方向键导致方向被缓存但不生效。恢复之后蛇会朝一个你没预料的方向走。处理办法是暂停时清空待生效方向或者暂停时干脆不接受方向输入。第四个是退出路径上的资源清理。如果你隐藏了光标却没有恢复终端后续的所有命令都会在没有光标的模式下运行很多人会以为终端坏了。这种问题排查起来很费劲因为用户不会想到是上一个程序留下的状态。5. 扩展方向与二次开发建议5.1 加障碍物与穿墙模式障碍物本质上是静态占位表加一个和地图同尺寸的布尔数组就行初始时随机撒若干个点但要避开蛇的初始位置和食物落点。绘制的时候在渲染阶段多一个分支判断碰撞判定也要多查一次这个表。穿墙模式则是把边界判定改掉坐标越界时不是死亡而是取模绕回另一侧。这里要注意取模的方向(x W) % W这种写法才能正确处理负数。改起来只有两行但游戏体验变化很大——穿墙会把贴边求生这个策略彻底瓦解玩家会更倾向于在地图中央游走这是个挺有意思的设计观察。5.2 双人对战状态管理的真正考验两个人玩同一个键盘一个用方向键一个用字母键逻辑上就是两套蛇的状态各自独立。但实践里你会发现碰撞判定一下子变复杂了A 的头撞到 B 的身体算谁死两条蛇头对头撞同一格怎么算我的建议是先把规则定死再动手写不要边写边想。我采用的规则是撞到对方身体则撞击方死亡两头同时进入同一格视为同归于尽吃到食物的一方加分。代码组织上这时候就该把蛇抽象成结构体了把坐标数组、头索引、长度、方向、分数全部打包进去然后所有函数都改成接受一个蛇指针。这一步重构做完你会发现原来的单人逻辑几乎不用改只是多传了一个参数。这就是前面说的数据结构选得好不好到扩展的时候会立刻体现出来。5.3 用脚本语言快速验证规则如果只是想验证玩法逻辑不想折腾编译和平台差异用脚本语言写一版原型其实更快。主循环结构和上面完全一样输入读取换成非阻塞模式光标定位也用同样的转义序列其余逻辑几乎是逐行翻译。我在调整速度曲线和障碍物密度这类参数的时候都是先在原型里调好再搬回编译型语言的版本里。原因是调参数这个过程要反复运行几十次能省一次编译就省一次。这个习惯我一直保留着现在做任何有数值调优的部分都会先出一个快速可迭代的版本。5.4 我一直遵守的几条编码习惯第一初始化游戏状态和数据结构的函数分开写不要混在main里。开局重来的时候只调初始化函数就行不用退出重开程序。第二所有常量集中定义在文件顶部地图宽高、初始长度、初始帧间隔、加速步长、帧间隔下限。这些东西你会反复调整散落在代码各处的话改一次要翻半天。第三渲染函数里不写任何状态变更。渲染只读只能填缓冲区。这条我吃过亏早期为了省事在渲染里顺手把光标位置也更新了结果后来加暂停功能的时候画面错位查了很久才发现是渲染带了副作用。第四每加一个新功能先跑一遍原有的边界用例贴着墙转弯、长度等于 4 时急转、吃到最后一个空格子。这三个用例能覆盖绝大部分回归问题我基本每次改完都会顺手跑一遍比写单元测试快得多虽然不够严格但对这个规模的程序足够用了。如果哪天你觉得这个 Demo 写完了没什么意思了我的建议是给它加一个回放功能把每一帧的方向记录下来结束时能重放整局。这个需求会逼着你想清楚哪些状态是确定的、哪些是随机的、随机种子怎么保存是往状态管理方向深入学习的一个很好的切入点。