NOKIA 那台经典单色机上的贪吃蛇，大概是很多人接触的第一个电子游戏：没有教程，没有存档，四个方向键，一格一格地挪。这些年带新人做入门项目，我习惯让他们用 Dev C++ 手写一遍控制台贪吃蛇，原因很简单——这个题目小到能在两百行内写完，又大到能把游戏循环、输入采样、坐标映射、碰撞判定、画面刷新这几件事全部串起来。它不像图形库项目那样把注意力耗在环境配置上，也不像纯算法题那样只跑一次结果就结束，你写完之后是真的能坐下来玩两把，手感不对立刻就能感觉到。这篇文章就是把这套东西完整拆开：从 Dev C++ 的工程怎么建、编译选项怎么勾，到帧率为什么不能用 Sleep 硬顶、蛇身该用什么结构存、画面为什么绝对不能每帧清屏、吃到食物那一帧到底发生了什么。目标不是让你抄一份代码跑通就完事，而是让你搞明白每一个选择背后的原因，之后想改成穿墙版、加速版、双人对战版都能自己动手。哪怕你只学过一学期 C 语言，照着往下读也不会有障碍。
1. 为什么这个项目我坚持用 Dev C++ 起手
1.1 复刻的核心是节奏，不是画面
经典机上的贪吃蛇，屏幕只有几十像素宽，蛇就是一个一个的黑方块，动作是跳变的，不是平滑移动的。你能记住这个游戏，靠的不是美术，而是那种“按下去立刻拐弯”“吃到东西顿一下”“撞墙马上结束”的反馈节奏。这背后对应的是三件事：固定的时间片（每帧多长时间推进一格）、非阻塞的输入采样（按键随时能进，但不能让程序卡在等待里）、以及准确的碰撞判定（什么时候算撞、什么时候算安全）。
所以我在做这个练习时，第一优先级是把时间片和输入这两件事做对，而不是把字符画得多漂亮。很多人第一次写贪吃蛇，会写成“画一帧 → 等按键 → 再画一帧”的阻塞式结构，结果就是蛇不动，按一下才走一步。这个结构在纯文本菜单程序里没问题，放在实时游戏里就是致命的。想清楚这一点，后面所有的代码组织方式都会跟着变。
1.2 Dev C++ 在这类小项目里的真实定位
Dev C++ 是个老牌轻量 IDE，自带 MinGW 系的编译器（常见版本是 TDM-GCC 4.9.2），装完就能用，不需要额外配环境变量。它的优点很明确：新建一个源文件，按 F11，黑框立刻弹出来，中间不经过任何工程向导、不生成一堆中间目录。对于一个两百行的控制台程序来说，这种“零仪式感”的体验是它最大的价值。
但它的短板也必须提前说清楚，否则你会在中途卡住。第一，版本老，编译器对 C++ 新标准的默认支持有限，如果你想用auto、范围 for、nullptr这些写法，得手动加编译参数。第二，调试器偏弱，断点能打，但变量观察窗口经常不那么顺手，所以我更推荐用“打印中间状态”这种土办法排查。第三，默认的文件编码处理比较粗糙，中文字符串在控制台里很容易变成乱码。这三点在后面的章节里都会给出具体处理办法。
提示：Dev C++ 有多个分支版本，界面和菜单位置略有差异，但“工具 → 编译选项”这个入口基本一致。找不到的话直接在菜单里翻一遍，不要凭记忆点。
1.3 三分钟把工程骨架立起来
具体步骤非常短，但每一步都有个容易忽略的点：
- 启动 IDE，按
Ctrl + N新建源文件。 - 立刻按
Ctrl + S保存，文件名写成snake.cpp。这一步不能省，因为很多编译行为（比如是否按 C++ 规则解析）跟扩展名绑定，存成.c之后你写int& x这类引用会直接报错。 - 打开“工具 → 编译选项 → 编译器”，勾选“编译时加入以下命令”，填入
-std=c++11。如果你的代码里完全不用 C++11 特性，这一步可以跳过；但只要你想用nullptr或者初始化列表，就必须加。 - 按
F11（编译并运行）。第一次会提示保存，确认即可。
这个流程我走过很多遍，最常出问题的不是编译，而是运行窗口。Dev C++ 启动的控制台窗口默认缓冲区很高（常见是 300 行），这意味着你即便只输出十几行，缓冲区也已经铺开了。后面用坐标定位输出时，如果坐标算错超出了可见区域，控制台会整体滚动，画面立刻错位。解决办法在 3.3 节讲。
1.4 动手前先排掉三个隐性雷
第一个是编码。Dev C++ 编辑器默认按系统本地编码保存文件，简体中文环境下就是 GBK。如果你的控制台代码页也是 936，中文注释和中文提示都能正常显示；一旦你把文件另存成 UTF-8，printf("游戏结束")就会输出一串问号或者方块。我的做法是：源代码里所有会被打印到屏幕的字符串一律用英文和符号，注释用中文没关系，因为注释不参与输出。
第二个是窗口尺寸。控制台默认 80 列宽、25 行高左右，而贪吃蛇的棋盘如果按每格两列来算，25 格宽就要 50 列，加上边框和状态栏正好卡在边缘。稳妥的做法是在main开头直接改窗口：
system("mode con cols=66 lines=28");这条命令走的是系统的命令行解释器，会重建控制台窗口尺寸。注意它必须在任何输出之前调用，否则已经画出来的内容会被截断或错位。
第三个是“快速编辑模式”。这个坑我踩过不止一次：程序跑起来之后，你如果不小心用鼠标在控制台窗口里点了一下、拖选了一段文字，整个进程会立刻挂起，因为是控制台子系统在等你完成选择操作，_getch自然也就阻塞了。表现出来的现象就是“蛇突然不动了，按什么键都没反应”，新手往往会以为是自己代码写死循环了。运行前在控制台标题栏右键 → 属性 → 选项里，把“快速编辑模式”的勾去掉，能省掉大量误判。
2. 帧、按键与时间片：把老机器的节奏翻译成 Windows 参数
2.1 Sleep 从来都不精确，别拿它当节拍器
Windows 下Sleep(60)的实际休眠时间通常在 62 到 78 毫秒之间浮动，因为系统默认的计时器分辨率大约是 15.6 毫秒，一次休眠会被向上取整到最近的调度节拍。这意味着如果你写Sleep(speed)作为唯一的时间控制，实际帧长会比你设定的长出 10% 到 30%，而且这个误差还会随系统负载变化，导致游戏速度飘忽。
我采用的办法是“先记账，再补差”：每帧开头记录一个时间戳，逻辑和绘制跑完之后，算出这一帧已经花掉多少时间，只补足剩余的部分。
DWORD t0 = GetTickCount(); // ... 本帧的逻辑与绘制 ... while ((long)(t0 + speedMs - GetTickCount()) > 0) { Sleep(1); }这样写的好处是，帧长由时间戳决定，Sleep(1)只是让出 CPU，误差不会累积。代价是 CPU 占用会略微上升，对于这种小游戏完全无所谓。如果你追求更精细的控制，可以引入timeBeginPeriod(1)把系统计时器精度提到 1 毫秒，但那需要额外链接winmm库（在 Dev C++ 里是往编译选项里加-lwinmm），对贪吃蛇这种一帧一百多毫秒的游戏来说属于过度设计，我不建议一开始就上。
2.2 靠_kbhit轮询，绝不能用_getch等
_getch()是阻塞的：没有按键它就不返回，程序就停在那里。这在“按任意键继续”的场景里正好用，放进游戏主循环就是灾难。正确的做法是用_kbhit()先问一句“缓冲区里有没有按键”，有才去取。
while (_kbhit()) { int c = _getch(); // 处理按键 }注意这里是while不是if。因为两次帧之间的间隔可能有一两百毫秒，玩家在这个窗口里可能连按好几下，键盘缓冲区会攒下多个字符。如果你只取一个，剩下的会留到下一帧，表现出来就是“按了三下只转了一次弯，第四下才突然转过来”——手感非常怪。用while一次性把缓冲区读空，只保留最后一个有效方向，才是正确的处理方式。
2.3 方向键是两字节，0xE0前缀必须处理
用 WASD 写测试很方便，但真正玩的时候大家下意识会按方向键。方向键在控制台里不是单个字符，它先发一个前缀字节（通常是0xE0，也有0x00的情况），再发一个扫描码。如果你只读一次_getch，拿到的是那个前缀，它会被当成一个普通字符，代码里判断不出任何方向，按键就“失灵”了。
int c = _getch(); if (c == 0 || c == 224) { // 0x00 或 0xE0 int scan = _getch(); // 再读一次拿扫描码 if (scan == 72) c = 'w'; // 上 else if (scan == 80) c = 's'; // 下 else if (scan == 75) c = 'a'; // 左 else if (scan == 77) c = 'd'; // 右 else c = 0; // 其它功能键，直接丢弃 }这里有个细节：_getch()返回的是int不是char，因为要能表达 0 到 255 的全部取值，还要能返回 -1 表示失败。如果你用char接，0xE0在有的编译环境下会变成负数，判断c == 224就永远不成立，方向键彻底废掉。这个坑非常隐蔽，代码能编译、能运行、就是方向键没反应，排查起来很浪费时间。
2.4 一帧只认一次转向，否则会“反向自杀”
这是贪吃蛇里最经典的死法，也是我见过最多人写错的地方。假设蛇正在向右走，玩家在同一个帧内迅速按下“上”又按下“左”。如果你每读到一个方向就立刻覆盖，那么这一帧结束后方向会变成“左”，而“左”和当前的“右”正好相反，蛇头直接撞进自己的第二节身体，游戏结束。玩家会觉得莫名其妙：我明明先按的上。
正确的做法是：每帧最多接受一次方向变更，而且校验要和“当前实际生效的方向”比对，不是和“待生效的方向”比对。
int nd = -1; // ... 从按键解析出 nd ... if (nd >= 0 && (dir + 2) % 4 != nd) { // 方向编号 0上 1右 2下 3左 nextDir = nd; hasNext = 1; }(dir + 2) % 4就是当前方向的反方向。只要新方向不等于反方向，就接受。一旦hasNext被置为真，本帧的输入采样就停下来，剩下的按键留给下一帧处理。这样既保证了一帧只转一次，又不会把玩家的连续操作全部吞掉。
注意：如果你希望手感更跟手，可以把按键采样抽成一个函数，在帧末的等待循环里也持续调用。这样帧长不变，但按键的响应延迟从“最多一帧”降到“几毫秒”，玩起来会明显利落。代价是代码结构稍微复杂一点，建议先把基础版跑通再加上去。
3. 蛇身到底怎么存：从整体搬移到环形队列
3.1 先写个朴素版本把逻辑跑通
最直观的存法是两个平行数组，snakeX[]和snakeY[]，下标 0 永远表示蛇头，下标越大越靠近尾巴。移动时从尾巴开始，把每一节的数据往前挪一位，最后把新算出来的蛇头坐标写到下标 0。
for (int i = len - 1; i > 0; i--) { snakeX[i] = snakeX[i - 1]; snakeY[i] = snakeY[i - 1]; } snakeX[0] = nx; snakeY[0] = ny;为什么要从尾往头搬？因为如果从头往尾搬，你把snakeX[0]写到snakeX[1]之后，snakeX[1]的旧值就被覆盖了，下一轮读到的就是已经被改过的数据，整条蛇会瞬间叠成一团。这个顺序问题在数组复制类操作里非常常见，写的时候要养成“确认读写不冲突”的习惯。
这个版本的时间复杂度是 O(n)，n 是蛇长。对于一条最长几十节的蛇来说，每帧几十次赋值，性能上完全没感觉，所以我建议第一版就用它，逻辑清晰、容易调试。
3.2 环形队列版：把每帧的搬运降成常数操作
蛇再长一点、帧率再高一点，O(n) 的搬运就有点浪费了。更漂亮的做法是环形队列：开一个固定大小的数组，用头指针head和尾指针tail标记当前有效区间。移动时只需要让头指针前进一格、写入新坐标，再让尾指针前进一格，就完成了“整体前移”。
#define MAXLEN 500 // 至少等于棋盘格数 int bufX[MAXLEN], bufY[MAXLEN]; int head = 0, tail = 0, cnt = 0; void pushHead(int x, int y) { head = (head + 1) % MAXLEN; bufX[head] = x; bufY[head] = y; cnt++; } void popTail() { tail = (tail + 1) % MAXLEN; cnt--; } int getAt(int i) { // i = 0 表示蛇头 return (head - i + MAXLEN) % MAXLEN; }吃食物的时候只调pushHead不调popTail，长度自然增加；正常移动时两个都调，长度不变。整个操作的代价是常数级，跟蛇有多长无关。
这种写法的代价是可读性下降。(head - i + MAXLEN) % MAXLEN这种下标换算，第一次看要愣一下。所以我的建议是：先写数组搬移版，跑通、能玩、逻辑确认无误之后，再考虑换环形队列。一上来就追求最优数据结构，很容易在取模下标里绕不出来，最后连哪里写错了都定位不到。
3.3 坐标换算：为什么列坐标要乘 2
控制台是字符网格，一个半角字符占 1 列，一个全角字符（比如汉字、日文假名）占 2 列。经典机的蛇是方块，很多人第一反应是用■这种实心方块来画。问题在于，一旦你用全角字符，棋盘每格的实际屏幕宽度就变成 2 列，但你的坐标计算如果还是按 1 列算，所有位置全都会错位，蛇看起来是歪的。
两种解法：要么全部用半角字符，逻辑坐标直接当屏幕坐标用；要么固定每格占 2 列，坐标换算时统一乘 2。我选后者，因为 2 列的格子在视觉上更接近原版的方块比例，而且不会被不同字体的字符宽度搞乱。
void drawCell(int x, int y, const char* s) { gotoxy(x * 2 + 1, y + 1); // +1 是给左边框和上边框让位 printf("%s", s); }蛇身画"o "（字符加一个空格），食物画"* "，擦除画" "（两个空格）。这个空格不是多余的，它保证了每个格子只有一个可见字符，横向间距均匀，看起来才像“格子”而不是“一串字符”。
3.4 自噬判定为什么要放过尾格
判断蛇头撞到自己时的循环范围，直接写i < len是不对的。因为在正常移动（没吃到食物）的那一帧，尾巴那一节会离开原位，蛇头移到尾巴原来的位置是合法的，视觉上就是蛇头贴着尾巴绕过去。
int bodyLen = eat ? len : len - 1; // 没吃到食物时，尾巴会移走，不算碰撞 for (int i = 0; i < bodyLen; i++) { if (snakeX[i] == nx && snakeY[i] == ny) { gameOver = 1; break; } }eat为真的时候，尾巴不动，长度加一，所以整条蛇都在原地，必须全部检查。这个分支如果写反了，会出现两种极端：要么蛇头一碰尾巴就死（明明应该能钻过去），要么蛇可以穿过自己的身体（吃到食物的那一帧留下了漏洞）。两种都很难靠肉眼看出来，我建议在调试时专门设计两条路线各走一遍。
4. 画面为什么绝对不能每帧清屏
4.1gotoxy与光标隐藏
控制台的光标定位靠SetConsoleCursorPosition，传一个COORD结构体，里面是列和行。
void gotoxy(int x, int y) { COORD pos; pos.X = (SHORT)x; pos.Y = (SHORT)y; SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), pos); }窗口左上角是 (0, 0)。stdout的句柄通过GetStdHandle(STD_OUTPUT_HANDLE)拿，这两个调用在所有 Windows 控制台程序里都通用。
顺便把光标藏起来。光标在游戏里闪来闪去非常干扰视线，尤其是它恰好停在蛇身上的时候，你会以为多画了一格。
void hideCursor() { CONSOLE_CURSOR_INFO ci; ci.dwSize = 100; ci.bVisible = FALSE; SetConsoleCursorInfo(GetStdHandle(STD_OUTPUT_HANDLE), &ci); }dwSize必须在 1 到 100 之间，即使你只想隐藏光标，也得给个合法值，否则调用会失败。
4.2 局部刷新的核心：只擦尾巴、只画新头
如果你每帧都system("cls")再重画整个棋盘，会发生什么？cls是一次全屏清空，紧接着printf把几百个字符重新写进去。在刷新率低的时候，你能明显看到画面先变黑、再一行行刷出来，这就是闪烁。帧率越高闪得越厉害，因为屏幕大部分时间都处在“正在被重写”的中间状态。
正确做法是“最小改动”：每帧只需要处理三个位置——擦掉尾巴原来的格子、把旧蛇头改成身体字符、在新位置画出蛇头。
// 没吃到食物：尾巴会移走，先擦掉 drawCell(snakeX[len-1], snakeY[len-1], " "); // 数据前移之后，原蛇头已经变成 snakeX[1] drawCell(snakeX[1], snakeY[1], "o "); drawCell(snakeX[0], snakeY[0], "@ ");每帧实际写入的字符只有六个左右，屏幕其余部分完全不动，画面自然就稳了。这个思路在图形编程里叫“脏矩形”，在控制台里同样适用。
4.3 输出缓冲区：最容易被忽略的错位元凶
这是我在这个项目里踩得最深的一个坑。stdout连到控制台时默认是行缓冲的，也就是说printf的内容不一定立刻落到屏幕上，可能还躺在缓冲区里等着。当你连续调用gotoxy改变光标位置，缓冲区里那些“本该写到旧位置”的字符会在下一次刷新时才吐出来，落到新位置上，结果就是画面随机错位、出现重影。
现象非常诡异：跑着跑着某些格子突然多了个字符，或者蛇身断开一段。你盯着代码看半天，逻辑完全正确，问题其实出在缓冲区。
解决办法是在main开头把缓冲关掉：
setvbuf(stdout, NULL, _IONBF, 0);_IONBF就是无缓冲，每次printf立刻输出。对于这种高频定位写入的场景，无缓冲反而是对的，因为控制台本身已经是逐字符渲染了，我们不需要再从中间加一层缓存。
提示：如果关闭缓冲之后输出仍然偶发错乱，检查一下是不是某处用了
putchar或std::cout混着写。C 和 C++ 两套 IO 混用时的同步问题也会导致顺序错乱，统一用printf最省心。
4.4 边框、状态栏与重开时的清理
边框只需要画一次。上下两条横线用+和-拼，左右两条竖线逐行写|。画完之后游戏过程中就不用再管它了。
状态栏放在棋盘下方空一行，用gotoxy定位到固定行，每次整行覆盖输出，末尾补足空格防止残留：
gotoxy(0, H + 3); printf("Score: %-6d Speed: %-4d Len: %-4d WASD move, ESC quit ", score, speedMs, len);%-6d这种左对齐加宽度的写法，能让数字位数变化时后面内容不跟着跳。末尾那几个空格是为了覆盖上一帧更长的内容——比如分数从 100 变成 90，如果不补空格，屏幕上会残留一个0。
重开一局的时候，system("cls")是可以用的，因为那是两次游戏之间的切换，闪一下没人介意。清屏之后要重新画边框、重新隐藏光标（某些情况下清屏会重置光标状态），然后再初始化蛇和食物。
5. 食物、计分与难度曲线：让“再来一局”变成条件反射
5.1 食物落点的重试策略
生成食物的逻辑看起来简单：随机一个坐标，如果落在蛇身上就重新随机。但这里有两个必须处理的边界。
第一，蛇填满整个棋盘时会死循环。理论上蛇长上限就是棋盘格数，真到了那一步，随机永远找不到空位。虽然实际玩到这一步的概率极低，但代码里必须防一手：
if (len >= MAXLEN) { foodX = -1; foodY = -1; return; } // 通关第二，随机数要先播种。不调srand的话，每次启动程序rand()的序列完全一样，第一颗食物永远出现在同一个位置，玩家第二次玩就会发现“怎么每次都一样”，怀疑人生。在main里调一次：
srand((unsigned)time(NULL));time(NULL)返回的是秒级时间戳，同一秒内多次启动程序序列会重复，但对这个游戏来说毫无影响。
关于重试效率：当蛇还短的时候，撞上蛇身的概率很低，几乎一次就中；蛇长超过棋盘一半之后，可能平均要试两三次。这个量级完全不需要优化，不要为了“优雅”去维护一个“剩余空格列表”，那是给更严格的场景准备的。
5.2 速度曲线：从 180 毫秒到 60 毫秒
经典机的难度是阶梯式上升的，每吃若干个食物提一档速。我用的是线性递减：
score += 10; if (speedMs > 60) speedMs -= 6;初始 180 毫秒，每吃一颗减 6 毫秒，吃到 20 颗左右就到 60 毫秒，然后维持不变。这个曲线我调过几轮，几点体会：
- 起始速度不能太快。180 毫秒一格，玩家有足够时间反应，前几颗食物是“送分”的，让人先建立信心。
- 终速不能太慢，60 毫秒已经是极限了。再快的话，键盘的响应延迟（一帧的采样窗口）会占掉很大比例，操作会变得不可控，玩家会觉得“我明明按了”。
- 递减幅度要小。我一开始写的是每颗减 15 毫秒，结果吃到第三颗就已经飞快，游戏寿命不到一分钟。减 6 是个比较舒服的值。
如果你想要更有层次的手感，可以改成“分段减速”：前 5 颗每颗减 8，中间 10 颗每颗减 4，后面每颗减 2。实现上就是几个if，不复杂，但手感会明显更像原版。
5.3 穿墙模式：一行宏开关带来的玩法差异
经典机上的贪吃蛇是有“撞墙即死”和“穿墙而过”两种模式的，后者在后期版本里很受欢迎。实现上只要把边界判定改掉：
#if WRAP if (nx < 0) nx = W - 1; if (nx >= W) nx = 0; if (ny < 0) ny = H - 1; if (ny >= H) ny = 0; #else if (nx < 0 || nx >= W || ny < 0 || ny >= H) gameOver = 1; #endif用一个#define WRAP 0/1控制，编译期决定，运行时零开销。穿墙模式下难度大幅下降，因为你可以绕着边缘跑，所以我会把起始速度调快一档来平衡。
注意穿墙之后，自噬判定仍然要做。有人改完穿墙就忘了这一点，结果蛇可以穿过自己的身体，游戏直接失去意义。
5.4 记录最高分：一局结束后的小钩子
最高分不需要存文件，用进程内的静态变量就够，因为大家一般会连着玩好几局才关窗口。
static int best = 0; if (score > best) best = score;游戏结束界面把best一起打出来，玩家就有了“再来一局”的动力。这个改动只有三行代码，但对留存的影响比加十个特效都大——它给了玩家一个明确的目标。
如果你确实想跨进程保存，最土的办法是往一个文本文件里写一行数字，启动时读回来。注意文件路径别用绝对路径，用相对路径（比如"best.txt"），否则换个目录运行就找不到了。读写失败要能容忍，直接当 0 处理，别让一个缺失的存档文件把游戏搞崩。
6. 真正卡住人的地方：Dev C++ 实战排查清单
6.1 编译阶段最常见的四类报错
我把这些年帮人看代码时遇到的编译问题归了归类，基本跑不出这四种：
| 报错关键词 | 真实原因 | 处理方式 |
|---|---|---|
'Sleep' was not declared | 没包含windows.h，或写成了小写sleep | 加#include <windows.h>，注意大写 S |
'kbhit' was not declared | 同一套头文件里函数名带下划线 | 用_kbhit和_getch，包含<conio.h> |
'nullptr' was not declared | 编译器按旧标准解析 | 编译选项加-std=c++11 |
undefined reference to 'time' | 漏了<time.h> | 补上头文件 |
第一类最坑的地方在于，sleep和Sleep在不同平台上都存在，但语义和头文件完全不同。看到“未声明”的报错，先检查大小写，比翻文档快得多。
另外提一句conio.h：这严格来说不是标准 C 头文件，是某些编译器提供的扩展。Dev C++ 自带的 MinGW 里有这个头，所以能直接用。如果你把代码拷到别的环境编译报错说找不到conio.h，那不是你写错了，是环境不同，需要换用其它方式读键盘。
6.2 能编译但运行不对，按这个顺序查
症状一：画面疯狂闪烁，或者整片重绘。八成是某处每帧调用了清屏。搜索一下代码里有没有system("cls")在循环内部。
**症状二：字符随机错位、重影、
