VC6贪吃蛇工程拆解：Win32消息循环与GDI双缓冲实战

简介：面向C++初学者与课程设计学习者的贪吃蛇游戏增强版工程源码，基于VC6.0与MFC实现，适合用来理解Windows图形界面游戏的基本开发流程。工程围绕蛇体类与链表节点类的“双类”设计展开，将蛇的位置、长度与移动、增长等行为封装起来，并用单链表动态维护蛇身，便于复习节点插入、删除与遍历等数据结构知识。包内共58个文件，以cpp、h源码和obj、sbr编译中间文件为主，另含bmp位图、ico图标、rc资源脚本及可执行文件，压缩包约8.98MB，保留完整VC6.0工程结构与调试产物。已有180人学习，可参考其键盘消息处理、定时器控制速度、界面绘制、游戏状态切换和异常退出等实现思路，并对照工程组织方式完成编译、调试与二次修改。

1. 打开就编译：一个 VC6 贪吃蛇工程凭什么还值得拆

前段时间有人丢过来一个.dsw文件，说双击能打开、F7 能编译，但蛇跑起来像在跳帧。我原本以为又是那种大学课程设计式的半成品——一个main.cpp塞两千行，全局变量满天飞。结果拆开发现不是：这个用 C++ 和 VC6 写的贪吃蛇增强版，把定时器驱动、环形数组存蛇身、双缓冲抗闪烁这三件事做得很干净，增强部分（加速、穿墙、障碍关卡、最高分存档）也没有把主循环搅烂。

真正值钱的地方在骨架，不在玩法。二十多年过去，Win32 + GDI 依然是理解“一个游戏循环长什么样”最短的那条路，而这份代码正好是一个不掺框架杂质的最小样本。想练 C++ 手感、想搞懂消息循环、想给老项目做二次开发的人，都能从里面拿到东西。

2. 工程结构：从 .dsw 到 GDI 的那条链路

VC6 的工程组织和现在 CMake 那一套完全不同，它靠.dsp（项目文件）和.dsw（工作区文件）描述“哪些 cpp 参与编译、链接哪些 lib、输出什么类型”。很多人拿到这种老工程第一反应是新建一个 VS 工程把源码拖进去，结果编译过了、跑起来一堆警告——因为字符集、WINVER宏、链接库这些东西全丢了。先看清结构再动手，比急着按 F5 划算。

2.1 目录与文件职责

一份结构正常的贪吃蛇增强版工程，职责划分通常是这样：

这个划分的关键点是：游戏逻辑不碰 GDI，绘制层不碰游戏状态机。game.cpp里只有坐标和格子，render.cpp里只有Rectangle、Ellipse、BitBlt。二次开发时想换皮肤，只动render.cpp；想加玩法，只动game.cpp。如果拆开发现逻辑和绘制搅在一起，那第一步就该做这个分离，不然后面每加一个功能都要碰一遍绘图代码。

提示：level.h单独成文件是个好习惯。地图用字符串画，一行就是屏幕上一行，改关卡不需要重新理解一遍碰撞算法。

2.2 消息循环与定时器：游戏的心跳

Win32 里没有“每帧回调”这种概念，所有节奏都靠SetTimer和WM_TIMER撑起来。这是整套代码里最值得先读懂的一段：

// main.cpp —— 标准 Win32 骨架，没有 MFC，依赖最少 int APIENTRY WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX wc = { sizeof(WNDCLASSEX) }; wc.style = CS_HREDRAW | CS_VREDRAW; wc.lpfnWndProc = WndProc; wc.hInstance = hInst; wc.hCursor = LoadCursor(NULL, IDC_ARROW); wc.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH); wc.lpszClassName = "SnakeWnd"; RegisterClassEx(&wc); // 客户区固定 600x480 = 30 格 x 24 格 x 20 像素 // 注意 WS_OVERLAPPEDWINDOW 带边框，窗口总尺寸会比客户区大 HWND hWnd = CreateWindowEx(0, "SnakeWnd", "Snake Enhanced", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 600 + 16, 480 + 38, NULL, NULL, hInst, NULL); ShowWindow(hWnd, nCmdShow); MSG msg; while (GetMessage(&msg, NULL, 0, 0)) { // 阻塞式取消息 TranslateMessage(&msg); DispatchMessage(&msg); } return (int)msg.wParam; }

GetMessage是阻塞的，没有消息时线程就挂在那儿不烧 CPU，这一点和现在游戏引擎的“忙等 + 垂直同步”完全不同。节奏全靠WM_TIMER推：定时器到点了系统往队列里塞一条消息，DispatchMessage送到WndProc，里面调一次GameTick。所以这里有个绕不开的事实——游戏速度 = 定时器间隔，想让蛇跑快，改的就是这个毫秒数。

CreateWindowEx里那个+16 / +38是边框和标题栏的补偿。这个数字随系统主题变，硬编码在 XP 上刚好，在 Win10 上可能会差几个像素，导致客户区被裁掉一点。稳妥的做法是先CreateWindowEx再用GetClientRect取实际尺寸反算格子大小，或者直接用AdjustWindowRectEx。

2.3 为什么不用 MFC 文档视图

VC6 时代建工程，向导默认给你两套选项：MFC AppWizard 和 Win32 Application。这份代码选的是后者，理由很实在。

MFC 的文档/视图结构是为“打开文件、编辑、保存”这类应用设计的，CDocument管数据、CView管显示、OnDraw负责画。拿来写贪吃蛇，你会被迫把蛇的状态塞进CDocument，把绘制塞进OnDraw，再为了定时器重绘去调Invalidate，绕了一大圈还在跟CDC指针打交道。真正需要的东西只有三个：一个窗口句柄、一个定时器、一块能画的内存 DC。Win32 直接给。

代价是得自己管资源释放。CreateCompatibleDC出来的 DC 和CreateCompatibleBitmap出来的位图都是 GDI 对象，数量有上限（默认每个进程 10000 个句柄），忘了DeleteObject跑久了就会画不出来。MFC 用CDC封装帮你兜了一部分，但也只是兜了一部分。自己写反而清楚——谁创建谁释放，写在注释里就行。

另外，纯 Win32 工程编译出来的 exe 只有几十 KB，扔 U 盘里就能跑，不依赖任何运行时。这个特性在老机器、教学机、离线环境里依然好用。

3. 核心模块拆解：蛇身、转向、食物、碰撞与渲染

逻辑层是这份代码里我最愿意推荐的部分。贪吃蛇看着简单，真写起来全是边界：蛇怎么存、转向怎么排队、食物怎么避开蛇身、撞自己怎么判定、尾巴那格算不算障碍。这五件事任何一件处理糙了，玩起来就是“玄学”——有时候能过，有时候莫名其妙就死了。

3.1 蛇身数据结构：环形数组代替链表

新手最容易写出来的版本是std::vector<Pos>或者链表：前进的时候push_front新头、pop_back旧尾。VC6 的 STL 实现又老又慢，链表的节点分散在堆上，每帧遍历一遍画图，cache 命中率惨不忍睹。

更稳的是环形数组：一块定长数组，头指针和尾指针在上面转圈，前进一格就是“头指针 +1 写入新坐标，尾指针 +1 丢弃旧尾巴”，全是 O(1)，没有内存分配。

// game.h —— 棋盘与蛇身的基础定义 #define COLS 30 // 横向格子数 #define ROWS 24 // 纵向格子数 #define CELL 20 // 单格像素，客户区 600x480 #define MAX_LEN (COLS * ROWS) // 蛇最长不超过格子总数 struct Pos { int x; int y; }; struct Snake { Pos body[MAX_LEN]; // 定长数组，栈上或全局，不动态分配 int head; // 蛇头所在下标 int tail; // 蛇尾所在下标 int nLen; // 当前长度 int dir; // 方向：0 上 1 右 2 下 3 左 };

三个下标的关系是：nLen决定蛇有多长，head和tail决定这nLen个格子落在数组的哪一段。当nLen == MAX_LEN时数组是满的，头尾重合，这时候不该再增长——满屏就该判通关了。

用环形数组有两个必须记住的坑。第一，任何时候遍历蛇身都要用(tail + i) % MAX_LEN，不能直接for (i = 0; i < nLen; i++)，因为数组在逻辑上是“绕”的。第二，MAX_LEN必须严格大于等于可能出现的最大长度，否则新头会覆盖旧身，画面上的蛇会自己断成两截，还不报错。

提示：MAX_LEN直接取COLS * ROWS最省心。贪吃蛇占满全屏本来就是通关条件，不会真的超。

3.2 转向输入队列：为什么不能直接改方向

这一条是血泪经验。新手版本通常是WM_KEYDOWN里直接snake.dir = VK_UP，本地跑得好好的，一到手速快的玩家手里就翻车：一帧之内连按上、左，蛇头先朝上再朝左，等于原地掉头，直接撞自己身上，玩家一脸懵。

根因是键盘消息的到达频率和定时器的频率不是一个量级。定时器 150ms 一次，键盘随手就能 30ms 一个，一帧里塞两三个方向太正常了。所以必须有个队列，把玩家输入缓存起来，每帧只消费一个。

// game.cpp —— 两级输入缓冲 static int g_dirQueue[2] = { -1, -1 }; // -1 表示空槽 void PushDir(int d) { // 取队列里最后一个有效方向作为比较基准 int last = (g_dirQueue[1] != -1) ? g_dirQueue[1] : g_dirQueue[0]; if (last == -1) last = g_snake.dir; // 禁止 180 度掉头：上(0)与下(2)、左(3)与右(1)互为反方向 if ((d + 2) % 4 == last) return; if (g_dirQueue[0] == -1) g_dirQueue[0] = d; else if (g_dirQueue[1] == -1) g_dirQueue[1] = d; // 两槽都满就丢弃，宁可丢输入也不能让蛇抽风 } int PopDir() { int d = g_dirQueue[0]; g_dirQueue[0] = g_dirQueue[1]; g_dirQueue[1] = -1; return d; // 返回 -1 表示本帧无输入 }

参数上有两个细节值得说。第一，方向编码用0/1/2/3对应上右下左，反方向就是(d + 2) % 4，这个映射关系一旦定下来，后面所有判断都能写成算术，不用switch。第二，判断基准取的是队列里最后一个方向而不是当前方向，否则“上→右→下”这种连续输入里，玩家按下时蛇头可能还没转到右，就会被误判成合法掉头。

只给两个槽位是有意的。多了没用——人手的反应速度撑不起一帧三次有效转向；少了会丢输入。两个刚好覆盖“这一帧的转向 + 下一帧的预输入”。

3.3 食物生成：随机不算完，还要排除蛇身

最朴素的写法是do { food = random(); } while (OnSnake(food));。蛇短的时候没问题，蛇长到占满半屏，这个循环会反复空转到让人怀疑人生，表现出来就是“吃到食物后卡一下”。

正确做法是先算出所有空格子，再从里面随机挑一个：

// game.cpp —— 均匀、无重试的食物生成 Pos SpawnFood(const Snake* s) { static char occupied[ROWS][COLS]; memset(occupied, 0, sizeof(occupied)); // 注意用 (tail + i) % MAX_LEN 遍历，环形数组不能顺序扫 for (int i = 0; i < s->nLen; i++) { int idx = (s->tail + i) % MAX_LEN; occupied[s->body[idx].y][s->body[idx].x] = 1; } int freeCnt = 0; static Pos cand[MAX_LEN]; for (int y = 0; y < ROWS; y++) for (int x = 0; x < COLS; x++) if (!occupied[y][x]) { cand[freeCnt].x = x; cand[freeCnt].y = y; freeCnt++; } if (freeCnt == 0) { Pos none = { -1, -1 }; return none; } // 满屏即通关 return cand[rand() % freeCnt]; }

cand和occupied都加了static，是为了避开 VC6 默认 1MB 栈空间——Pos cand[720]是 5.7KB，单次调用没事，但如果在递归或者深层调用里反复开，栈容易顶到上限。放静态区一次分配，后面反复用。

随机种子别忘了。rand()不给种子的话每次启动序列一模一样，玩家会发现“第一次的食物永远在右上角”。在WM_CREATE里调一次srand((unsigned)time(NULL))就够了，别每帧调，那样同一秒内的多次调用拿到的是同一个值。

3.4 碰撞与胜负判定

碰撞要分三类：撞墙、撞自己、撞障碍物。三者的判定顺序和边界都不一样，混在一起写容易出“明明没撞却死了”的怪事。

// game.cpp —— 返回值：0 安全 1 撞墙 2 撞自己 3 撞障碍 int CheckCollision(const Snake* s, int level) { Pos h = s->body[s->head]; // 1. 撞墙：穿墙模式开启时这一段整体跳过 if (!g_bWrap) { if (h.x < 0 || h.x >= COLS || h.y < 0 || h.y >= ROWS) return 1; } // 2. 撞自己：从 head-1 往前数 nLen-1 个，尾巴那格不算 for (int i = 1; i < s->nLen; i++) { int idx = (s->head - i + MAX_LEN) % MAX_LEN; if (s->body[idx].x == h.x && s->body[idx].y == h.y) return 2; } // 3. 撞障碍：关卡地图上的静态格子 if (g_levelMap[level][h.y][h.x] == '1') return 3; return 0; }

i从 1 开始、到nLen - 1结束，这个范围是关键。蛇头自己当然不能和自己比，所以要跳过i = 0；而尾巴那一格在下一步就要挪走了，理论上蛇头可以进去，所以也不比。如果老老实实从 0 比到nLen-1，蛇在贴近自己身体转弯时会莫名其妙死亡，这是最常见的翻车点之一。

穿墙的处理放在移动那一步更合适，而不是在碰撞里补救：

// 移动一格，返回是否吃到食物 int SnakeStep(Snake* s, Pos food) { static const int DX[4] = { 0, 1, 0, -1 }; static const int DY[4] = { -1, 0, 1, 0 }; Pos nh = s->body[s->head]; nh.x += DX[s->dir]; nh.y += DY[s->dir]; if (g_bWrap) { // 穿墙：取模回到另一侧 nh.x = (nh.x + COLS) % COLS; nh.y = (nh.y + ROWS) % ROWS; } int grow = (nh.x == food.x && nh.y == food.y); s->head = (s->head + 1) % MAX_LEN; s->body[s->head] = nh; if (s->nLen < MAX_LEN) s->nLen++; if (!grow) s->tail = (s->tail + 1) % MAX_LEN; // 不吃就不删尾 return grow; }

(nh.x + COLS) % COLS里的+ COLS不能省。C 语言里-1 % 30结果是-1，不是 29，直接写nh.x % COLS从左边界穿出去会变成负坐标，然后在下一帧被判定成撞墙。

3.5 双缓冲渲染：把闪烁摁死

GDI 直接往窗口 DC 上画，每画一个矩形屏幕就刷一次，蛇一动整片区域重绘，肉眼看到的就是闪。解决办法是老三样：内存 DC 上画完整帧，再一次性BitBlt贴过去。

// render.cpp —— 双缓冲，句柄只创建一次 static HDC g_memDC = NULL; static HBITMAP g_memBmp = NULL; void InitBackBuffer(HWND hWnd) { HDC hdc = GetDC(hWnd); g_memDC = CreateCompatibleDC(hdc); g_memBmp = CreateCompatibleBitmap(hdc, COLS * CELL, ROWS * CELL); SelectObject(g_memDC, g_memBmp); // 换掉默认的 1x1 单色位图 ReleaseDC(hWnd, hdc); } void DrawFrame(HWND hWnd) { RECT rc = { 0, 0, COLS * CELL, ROWS * CELL }; FillRect(g_memDC, &rc, (HBRUSH)GetStockObject(BLACK_BRUSH)); DrawGrid(g_memDC); // 淡色网格线 DrawLevel(g_memDC); // 障碍墙 DrawFood(g_memDC, g_food); // 食物 DrawSnake(g_memDC, &g_snake); // 蛇，头深尾浅 HDC hdc = GetDC(hWnd); BitBlt(hdc, 0, 0, COLS * CELL, ROWS * CELL, g_memDC, 0, 0, SRCCOPY); ReleaseDC(hWnd, hdc); }

配合WndProc里一句case WM_ERASEBKGND: return 1;，闪烁基本就没了。这句的意思是“背景我自己擦，系统你别管”；少了它，系统会在WM_PAINT之前先用背景刷子刷一遍白，双缓冲白做了。

还有个细节：SelectObject之后拿到的旧位图对象（那张 1×1 单色位图）不需要保存，但g_memBmp在窗口销毁时必须DeleteObject。少了这一步，每次重开一局就泄漏一个位图句柄，跑上几十次之后CreateCompatibleBitmap会返回 NULL，画面直接全黑。

4. 增强点怎么落地：加速、穿墙、障碍、存档

基础版能玩之后，“增强”才是这份代码真正的分水岭。但增强最容易搞成堆砌——加一堆开关，代码里到处if (g_bXXX)，最后连自己都记不清哪条路径。稳妥的做法是先把状态机理清楚，再把每个增强点做成一块可以独立开关的模块。

4.1 速度曲线与定时器重设

提速不是改一个变量就完事，它同时牵扯定时器、分数、玩家预期三件事。

// game.cpp —— 吃到食物后的处理 void OnEatFood(HWND hWnd) { g_nScore += 10; g_nEatCnt += 1; // 每吃 4 个提速一档，间隔减 10ms，最快 60ms 封顶 if (g_nEatCnt % 4 == 0 && g_nInterval > 60) { g_nInterval -= 10; // 同一个 ID 再调 SetTimer 是"替换"不是"新增"，旧的自动失效 SetTimer(hWnd, IDT_GAME, g_nInterval, NULL); } g_food = SpawnFood(&g_snake); if (g_food.x < 0) { g_state = GS_WIN; KillTimer(hWnd, IDT_GAME); } }

SetTimer的行为值得单独说一句：用同一个定时器 ID 再调一次，是重置而不是叠加。所以这里不用先KillTimer。但如果用了不同的 ID，就会同时存在两个定时器，WM_TIMER的wParam分别对应，蛇会跑出双倍速度——这是很多人调速度时踩的坑。

60ms 封顶是从手感出发的：再快人类的预判就跟不上了，格子只有 20 像素，蛇一帧跳一格，眼睛根本追不住。想要更高的难度感，靠加速度曲线不如靠障碍物密度。

4.2 障碍物关卡的数据描述

别用if (level == 1) { ... }一关一关写死。用字符串画地图，一行字符串就是屏幕上的一行，'1'是墙、'0'是空地：

// level.h —— 一张图就是一关，改关卡不用碰逻辑代码 static const char* g_levelMap[3][ROWS] = { { // 第 0 关：空场，只有四周边界 "111111111111111111111111111111", "100000000000000000000000000001", "100000000000000000000000000001", // ... 中间 20 行同理 "100000000000000000000000000001", "111111111111111111111111111111" }, { // 第 1 关：中间一道竖墙，留两个缺口 "111111111111111111111111111111", "100000000000000000000000000001", "100000000001111111000000000001", // 缺口在两侧 // ... 其余行略 "111111111111111111111111111111" }, { // 第 2 关：十字形障碍 "111111111111111111111111111111", "100000000000011000000000000001", "100000000000011000000000000001", // ... 其余行略 "111111111111111111111111111111" } };

这种写法的好处是所见即所得：改一关的难度，直接改字符串里的0和1，不需要理解碰撞算法，也不怕改出界。代价是每条字符串必须是COLS个字符，多一个少一个都会越界读——初始化时加一句assert(strlen(g_levelMap[l][y]) == COLS)能提前发现问题。

注意第 0 关把四周边界也画成墙了。这时候如果同时开了穿墙模式，取模会把你送到边界墙上，一穿就死。所以穿墙模式要么不允许在带边界墙的关卡开启，要么在碰撞检测里跳过边界那两行。我在自己改的版本里干脆把边界墙去掉，让COLS/ROWS自己就是边界，逻辑更干净。

4.3 最高分落盘

存档最简单的方式就是读写一个小文本文件，别上数据库、别上注册表。

// game.cpp —— 最高分读写 void LoadBest() { char path[MAX_PATH]; GetModuleFileName(NULL, path, MAX_PATH); // 取 exe 全路径 char* p = strrchr(path, '\\'); if (p) strcpy(p + 1, "best.ini"); // 同目录下换文件名 FILE* fp = fopen(path, "r"); if (fp) { fscanf(fp, "%d", &g_nBest); fclose(fp); } if (g_nBest < 0) g_nBest = 0; // 防止文件被写坏 } void SaveBest() { if (g_nScore <= g_nBest) return; // 没破纪录就不写盘 g_nBest = g_nScore; char path[MAX_PATH]; GetModuleFileName(NULL, path, MAX_PATH); char* p = strrchr(path, '\\'); if (p) strcpy(p + 1, "best.ini"); FILE* fp = fopen(path, "w"); if (fp) { fprintf(fp, "%d\n", g_nBest); fclose(fp); } }

为什么不用fopen("best.ini", "r")这种相对路径？因为相对路径的基准是“当前工作目录”而不是 exe 所在目录。双击运行的时候两者恰好一样，但从 IDE 里 F5 跑、或者从快捷方式启动，工作目录可能是别的地方，就会出现“明明玩出了高分，重开一局又归零”的诡异现象。GetModuleFileName拼绝对路径能一次解决。

写文件记得判空。fopen在只读目录、权限受限的时候会返回 NULL，直接fprintf(NULL, ...)在 VC6 里是崩溃而不是报错。

4.4 暂停与重开的状态机

增强功能一多，状态就容易乱。用一个枚举把状态收拢，所有输入和定时器逻辑先看状态再决定动不动：

// game.h enum GameState { GS_READY, GS_RUNNING, GS_PAUSED, GS_OVER, GS_WIN }; // wndproc.cpp —— 定时器里只处理 RUNNING case WM_TIMER: if (wParam == IDT_GAME) { if (g_state == GS_RUNNING) { int d = PopDir(); if (d != -1) g_snake.dir = d; GameTick(hWnd); } } return 0; case WM_KEYDOWN: switch (wParam) { case VK_UP: if (g_state == GS_RUNNING) PushDir(0); break; case VK_RIGHT: if (g_state == GS_RUNNING) PushDir(1); break; case VK_DOWN: if (g_state == GS_RUNNING) PushDir(2); break; case VK_LEFT: if (g_state == GS_RUNNING) PushDir(3); break; case VK_SPACE: if (g_state == GS_RUNNING) { g_state = GS_PAUSED; } else if (g_state == GS_PAUSED) { g_state = GS_RUNNING; } break; case 'R': GameReset(hWnd); g_state = GS_RUNNING; break; } return 0;

暂停的时候g_dirQueue里的残留要给清掉，不然恢复那一刻蛇会按暂停前最后一个输入拐弯，玩家会觉得“我明明没按”。GameReset里顺手g_dirQueue[0] = g_dirQueue[1] = -1;就干净了。

5. 踩坑排查：VC6 下跑这套代码最容易翻车的五处

这一节按“现象 → 原因 → 解决”写，都是我自己在这类老工程上真遇过的。

5.1 编译报 LNK2001，找不到PlaySound

现象：代码里写了PlaySound("eat.wav", NULL, SND_FILENAME | SND_ASYNC);，头文件也包含了mmsystem.h，编译阶段不报错，链接阶段报LNK2001: unresolved external symbol __imp__PlaySoundA。

原因：PlaySound属于 WinMM，VC6 的 Win32 Application 默认链接的是kernel32.lib user32.lib gdi32.lib这几个基础库，不含winmm.lib。

解决：Project → Settings → Link → Object/library modules那一行末尾补上winmm.lib（前面留一个空格）。或者在源文件顶部加一句#pragma comment(lib, "winmm.lib")，跟着代码走，换机器也不用重新配。

5.2 窗口一片黑，蛇根本不出来

现象：程序起来了，窗口是黑的，网格都没有。

原因：有三处可能，按概率排——一是WM_PAINT里没调DrawFrame，或者调了但 FM 里BeginPaint/EndPaint没配对，导致整块客户区被判定为“无效”；二是画图时坐标忘了乘CELL，三十来条线全挤在左上角几个像素里；三是WM_ERASEBKGND返回了 0，与双缓冲互相打架。

解决：先在DrawFrame末尾加一个Rectangle(g_memDC, 0, 0, 100, 100)当哨兵，红色方块出现了说明双缓冲链路是通的，问题在数据层；没出现就往上查WM_PAINT。坐标问题最简单——DrawSnake里所有x * CELL、y * CELL都检查一遍，漏乘一个就会全画到一个点上。

5.3 蛇一转弯就撞死自己

现象：长度到 4 以后，快速按键拐弯，时不时直接判死，位置看起来没撞到任何东西。

原因：方向是在WM_KEYDOWN里直接写给g_snake.dir的，一帧内收到两次按键，蛇头就按“先下后左”走了一步后再走一步，第二步正好在原来身体的位置上。定时器 150ms 一帧，人手一次双击就跨过去了。

解决：改成 3.2 节那种两级输入队列，每帧只出队一个方向，同时在PushDir里用(d + 2) % 4 == last拦掉 180 度掉头。改完之后手速再快也只会“拐一次”，多余输入被丢弃，不会出现幽灵式自撞。

5.4 分数一高画面就开始卡，越来越高

现象：前几百分流畅，蛇长到五六十节以后明显掉帧，切到任务管理器一看 GDI 对象数一直涨。

原因：DrawFrame里每次调用都CreateCompatibleDC+CreateCompatibleBitmap，用完只ReleaseDC没DeleteObject。GDI 句柄有配额，涨到上限之后创建全部失败，绘制就退化成全黑。

解决：把内存 DC 和位图挪到WM_CREATE里创建一次，全局保存，WM_DESTROY里DeleteObject(g_memBmp)加DeleteDC(g_memDC)。顺便在调试版里加个GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)打印到标题栏，能直观看到句柄数有没有稳定。

5.5 改完地图编译通过，一跑就崩在CheckCollision

现象：新加了一关，编辑完字符串，编译没错，进游戏切到那一关直接触发访问冲突。

原因：地图字符串长度和COLS不一致。少一个字符，g_levelMap[level][y][29]就读到了字符串结束符\0之外的区域；多一个字符，整行错位，后面所有行的判定全乱。

解决：初始化时统一校验，assert(strlen(g_levelMap[l][y]) == COLS)，在 Debug 下第一次跑就能定位到具体是哪一行。另外别用中文字符或者全角空格去排版地图，VC6 默认把源文件当本地编码读，一个中文字符占两字节，strlen数出来的值永远对不上。

6. 二次开发：把这套骨架搬到自己的练手项目上

我最推荐的一个改造方向是把渲染层彻底抽出来。现在DrawSnake里是Rectangle画方格子，改成贴图只需要换一个函数：准备一张snake_head.bmp、一张snake_body.bmp，用LoadImage加载成HBITMAP，再用SelectObject换进一个临时 DC，BitBlt贴到g_memDC上。逻辑层一行都不用改，因为Snake里只有格子坐标，不知道外面是矩形还是图片。

// render.cpp —— 用位图替换色块，逻辑层零改动 static HBITMAP g_bmpHead = NULL; static HBITMAP g_bmpBody = NULL; void LoadSkin() { g_bmpHead = (HBITMAP)LoadImage(NULL, "res\\head.bmp", IMAGE_BITMAP, CELL, CELL, LR_LOADFROMFILE); g_bmpBody = (HBITMAP)LoadImage(NULL, "res\\body.bmp", IMAGE_BITMAP, CELL, CELL, LR_LOADFROMFILE); } void DrawSnake(HDC dc, const Snake* s) { HDC tmp = CreateCompatibleDC(dc); for (int i = 0; i < s->nLen; i++) { int idx = (s->tail + i) % MAX_LEN; HBITMAP src = (i == s->nLen - 1) ? g_bmpHead : g_bmpBody; if (!src) { // 图没加载上就退回色块 RECT r = { s->body[idx].x * CELL, s->body[idx].y * CELL, (s->body[idx].x + 1) * CELL, (s->body[idx].y + 1) * CELL }; FillRect(dc, &r, (HBRUSH)GetStockObject(WHITE_BRUSH)); continue; } HGDIOBJ old = SelectObject(tmp, src); BitBlt(dc, s->body[idx].x * CELL, s->body[idx].y * CELL, CELL, CELL, tmp, 0, 0, SRCCOPY); SelectObject(tmp, old); // 一定要还回去 } DeleteDC(tmp); }

SelectObject之后必须把旧对象还回去再DeleteDC，这是 GDI 的硬规矩，忘了还就会出现“位图被删了但 DC 还引用着”的悬空句柄。if (!src)那个兜底也别省——图丢了程序还能跑，只是丑一点，比直接崩强。

第二个方向是加一个回放模式，把每一帧的方向和食物位置记进一个struct { short dir; short foodX, foodY; }数组，游戏结束后按原顺序重放。这个功能对调试特别有用：蛇莫名其妙死了，回放一遍就能看清是哪一帧的输入导致的问题，比盯着屏幕猜强得多。

第三个方向是把定时器换掉。SetTimer的精度受系统时钟节拍限制，默认 15.6ms 一跳，你设 60ms 实际可能是 62 或 78，高速时手感会飘。想稳就用timeGetTime()自己在消息循环里累加时间差，WM_TIMER只保留一个 15ms 的心跳做驱动。这一改，速度曲线才真正可控。

双人模式我试过一次，最麻烦的不是键盘分区，而是“两条蛇头对头撞在一起”该怎么判。现在的逻辑是“先移动先判定”，谁先到GameTick谁就吃掉对方，结果是先手必胜。公平的做法是把两条蛇的下一步都算出来再统一判定，等于给GameTick加一个两阶段提交。这个改动会动到主循环结构，改之前一定先把单人的测试跑通、把回放录好，出问题能立刻对比。

从那以后我每次动这类老工程，都强制先跑一遍“最小可玩”回归：开局、吃三个食物、撞一次墙、按一次暂停、重开一局，五步全过再动新功能。这套流程救过我好几回，尤其是改地图和改渲染同时进行的时候。希望帮到你。

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