控制台贪吃蛇这个题目我前前后后写过四遍。第一遍照着教程抄跑起来蛇会穿墙第二遍是给一个同学讲指针时现写的写完发现吃食物不长大第三遍用纯 C 重写卡在画面狂闪和按键被吞上第四遍用 C11 从头撸了一遍才终于把它当成一个正经小工程来对待。如果你手上正在做这个项目或者被留了这个作业、面试里要现场写一段那这篇基本就是我这几遍踩完坑之后的完整复盘。它不复杂一个文件、几百行代码就能跑但它几乎把控制台程序该遇到的坑都集齐了非阻塞输入、时间步长、渲染刷新、随机数、容器选型这些点随便拎一个出来都能聊很久。下面我按为什么这么设计—核心机制怎么实现—怎么一步步跑起来—出问题怎么查的顺序讲代码是比较完整地贴出来的能直接编译复现。1. 先想清楚一个控制台贪吃蛇到底在练什么1.1 三十分钟版本和能讲二十分钟的版本市面上流传的贪吃蛇代码九成是同一个路子一堆全局变量蛇身数组、长度、方向、食物坐标一个while(1)里先Sleep(200)再system(cls)清屏然后双重循环把整个地图重画一遍最后_kbhit()判断有没有按键。这种写法能跑但也仅限能跑。问题集中在三处system(cls)每帧调用一次外部进程闪烁肉眼可见Sleep的精度受系统调度影响越到后面越飘方向变量被直接赋值玩家手快连按两下就能让蛇原地掉头撞死自己。正经写一版需要解决的是另外几个问题输入和游戏逻辑解耦——按键只负责往队列里塞方向什么时候生效由逻辑层决定渲染和逻辑解耦——逻辑按固定步长推进渲染按屏幕刷新率跑两者不绑定时间用单调时钟累积——而不是靠Sleep的调用次数状态集中管理——一个GameState枚举顶掉一堆bool标志位。这四件事做完代码量其实没多多少但整个东西的性质变了从作业变成了小工程。这也是我推荐用 C11 重写的原因上面这四个问题C11 恰好都给了顺手的工具。std::chrono::steady_clock解决单调时钟std::deque解决蛇身头尾增删enum class解决方向枚举的命名污染和隐式转换std::mt19937解决随机数质量。用老写法硬凑也能凑出来但写起来别扭读起来更别扭。1.2 C11 在这个项目里的真实落点我不太喜欢那种为了用而用的写法比如硬塞一个std::shared_ptr进去。下面这张表是我实际用到的特性以及它们各自解决的具体问题不是罗列C11 特性在这个项目里的位置解决的实际问题enum class Dir方向定义避免UP/DOWN和别的常量撞名也禁止了int隐式转枚举std::chrono::steady_clock主循环计时不受系统时间调整影响比clock()和Sleep计数靠谱std::mt19937食物随机生成替代rand() % n的取模偏差周期足够长std::dequePoint蛇身存储头部插入、尾部删除都是 O(1)vector头部插入要整体搬移std::vectorPoint空格子收集食物生成时的一次性候选池随机取下标auto/ 范围 for遍历蛇身少写一堆迭代器类型名改容器类型时不用改遍历代码constexpr地图宽高、速度常量编译期确定数组大小可以用它类内成员初始化Point的坐标、游戏状态构造函数不用一个个写初始化列表nullptr指针初始化避免0和NULL的重载歧义std::to_string分数显示拼 HUD 字符串不用sprintf开缓冲区真正有含量的就前三行时钟、随机数、容器。剩下的属于顺手改善可读性。我一直觉得判断一个项目该不该用新特性标准很简单——用了之后代码是变短了还是变长了读的人是多花时间还是少花时间。按这个标准上面这些是划算的。1.3 技术选型为什么不上图形库、不引第三方库每次聊到控制台游戏总有人问为什么不用 SFML / SDL。我的答案很直接这个项目的重点是游戏循环和状态管理不是渲染。一旦引入图形库你的时间会花在窗口创建、纹理加载、事件循环适配、跨平台库配置上这些内容和贪吃蛇的核心逻辑一点关系都没有纯粹是噪音。同理ncurses这类终端控制库也不必要。它确实能省掉跨平台按键读取的麻烦但它会给你带来新的依赖而且它的窗口刷新模型对新手来说又是一层心智负担。我们需要的终端能力只有三样定位光标、读取单个按键、关闭行缓冲和回显。这三样东西Windows 是SetConsoleCursorPosition_kbhit/_getch 默认就好Linux 是 ANSI 转义序列 termiosselect加起来不到五十行条件编译。一个前置提醒控制台方案的天花板很低字符尺寸、颜色、动画都受限制。别在这儿追求画面好看把精力放在逻辑正确性和代码结构上那才是能带走的东西。2. 架构与数据模型动手前先画好这张图2.1 输入、逻辑、渲染三层分离整个程序我切成三块数据流向是单向的输入层每帧把键盘缓冲区里的所有按键全部取出交给游戏对象游戏对象只做一件事——往待处理方向队列里塞数据不直接改蛇头朝向。逻辑层按固定时间步长Step()每次推进一格内部完成方向生效、碰撞检测、吃食物判定、分数更新、食物重生。渲染层拿到当前游戏状态的快照拼一个长字符串一次性输出到终端。为什么要拆这么干净因为拆了之后每一层的问题都能独立定位。画面花了是渲染层的事蛇走位怪是逻辑层的事按键没响应是输入层的事。混在一起的代码出了问题你只能全局猜。而且分层之后有个额外好处逻辑层完全不碰任何 I/O这意味着你可以写单元测试——比如构造一个场景调十次Step()断言蛇头坐标和游戏状态。控制台程序也能量测试这一点很多人没意识到。2.2 蛇身容器选型std::deque 还是 std::vector这是这个项目里最值得聊的一个选型。蛇的移动本质是头部新增一节尾部删掉一节吃了食物则尾部不删。也就是头插尾删。三种候选方案对比容器头部插入尾部删除随机访问内存连续性结论std::vectorO(n)整体搬移O(1)支持连续蛇长几十节时开销可忽略但语义别扭std::dequeO(1)O(1)支持分段连续首选语义和操作复杂度都匹配std::listO(1)O(1)不支持节点分散判重用不了随机访问反而更慢蛇长最多也就几百节vector的头插开销其实完全扛得住但用deque的理由不只是性能是语义匹配。代码里push_front和pop_back写出来任何人扫一眼就知道这是队列结构用vector配合insert(begin(), ...)和pop_back()读代码的人会下意识觉得这里是不是写错了。另外避免用list因为碰撞检测需要遍历蛇身判断某个坐标是否被占据list的缓存不友好而且没有下标访问会逼你写一堆迭代器。约定上我选蛇头在front()。这样snake_.front()永远是当前头snake_.back()永远是尾。也有代码把头放back()也不是不行但每次取头都要back()读起来反直觉。2.3 网格坐标系与尺寸参数怎么定地图定成 30 列 × 20 行也就是 600 个格子。这个数字不是拍脑袋定的常见终端窗口宽度是 80 字符扣掉边框和边距留给游戏区的大约 60 字符而终端字符的宽高比大概是 1:2也就是一个字符宽约等于半个字符高。所以每个格子横向占两个字符宽度30 格 × 2 60 字符宽20 格 × 1 字符高 20 行画出来视觉上正好接近正方形。如果每格只输出一个字符你会得到一个扁扁的、横向拉伸的地图蛇的移动速度看起来上下快、左右慢——因为同样是一格位移横向看着短、纵向看着长。这个细节很多人不注意第一次做出来的版本总感觉手感不对八成就是这个原因。constexpr int kWidth 30; // 横向格子数 constexpr int kHeight 20; // 纵向格子数 constexpr int kCellChar 2; // 每格占用字符宽度用于修正终端字符宽高比坐标系我选左上角为原点 (0,0)x 向右增y 向下增。这样和终端光标的行列方向一致渲染的时候不用做任何翻转是个纯粹的偷懒决定但确实能省掉一堆kHeight - 1 - y的换算。2.4 状态机四种状态跑完整个生命周期游戏状态我定义为四个Ready还没开始、Running进行中、Paused暂停、Over结束。用enum class定义enum class GameState { Ready, Running, Paused, Over };用enum class而不是普通enum最实际的原因是普通枚举的成员会泄漏到外层作用域。你定义enum { Over, Paused }那Over就变成了全局可见的标识符很容易和别的东西撞名。enum class强制写成GameState::Over而且不允许隐式转成intif (state 3)这种写法直接编译不过——这算是一种保护。状态迁移的规则很简单但必须写死不能散落各处Ready收到任意移动键 →RunningRunning按下暂停键 →Paused再按一次 →RunningRunning撞墙或撞自己 →OverOver按下重开键 → 重置所有数据回Ready状态迁移集中处理的好处是你不用在每个函数开头写一堆if (paused) return;。只有Step()和输入处理需要检查状态其余函数无脑执行。3. 核心机制的实现细节3.1 帧循环与时间步长把速度变成可调参数Sleep(200)这种做法最大的问题是它把游戏速度和主循环节奏绑死了。想让蛇加速你得改睡眠时长想让画面刷新更流畅又得改睡眠时长——两个需求打架。正确做法是用累加器模式主循环以极高频率空转每圈睡 1 毫秒同时用单调时钟测量真实流逝的时间把流逝的时间累加到一个变量里只要累加值超过当前步长就推进一次逻辑并把累加值减去步长。auto last std::chrono::steady_clock::now(); int64_t acc 0; while (game.Running()) { auto now std::chrono::steady_clock::now(); int64_t dt std::chrono::duration_caststd::chrono::milliseconds(now - last).count(); last now; if (dt 250) dt 250; // 关键钳制单帧最大时间 acc dt; int stepMs game.StepMs(); while (acc stepMs) { game.Step(); acc - stepMs; stepMs game.StepMs(); // 吃掉食物后步长可能变化要重取 } Render(game); std::this_thread::sleep_for(std::chrono::milliseconds(1)); }这里有两个细节都是踩过坑才加上的。第一个是dt钳制。如果不加用户把窗口切走十秒钟再切回来dt就是 10000累加器瞬间攒够几十步游戏会在几毫秒内疯狂推进几十格蛇直接飞出地图。钳制到 250 毫秒最多补跑一两步视觉上就是卡了一下不会崩。第二个是内层while里重新取stepMs。因为蛇吃到食物后速度档位可能提升步长变小。如果只在循环外用一次stepMs加速会延迟一帧生效虽然影响极小但逻辑上不干净。速度曲线我这么设计基础步长 180 毫秒每吃 5 个食物提升一档每档减 15 毫秒下限 70 毫秒。int StepMs() const { int level score_ / kFoodPerLevel; // kFoodPerLevel 5 int ms kBaseStepMs - level * kStepDecrementMs; // 180 - level * 15 return ms kMinStepMs ? kMinStepMs : ms; }算一下0 到 4 分是 180ms5 到 9 分是 165ms10 到 14 分是 150ms……到 40 分时按公式是 180 - 8×15 60ms已经低于下限被封在 70ms。也就是说 40 分之后速度不再变化。下限 70ms 的理由很实在再快的话普通人眼和手指就跟不上了而且主循环每圈睡 1ms70ms 一步大概能分到 70 帧渲染不撕裂。低于 50ms 人就基本没法玩了那是给机器玩的。3.2 转向输入队列解决一帧内连按三个方向自杀的经典坑这是新手代码里最高频的 bug值得单独展开。假设蛇向右移动玩家手快在一帧之内依次按了上和下。如果代码是直接赋值// 错误写法 if (!IsOpposite(newDir, dir_)) dir_ newDir;第一次按上dir_是右上不是右的反向赋值成功dir_变成上。第二次按下此时dir_已经是上下是上的反向会被拒绝——这个分支恰好挡住了。但换个顺序就翻车向右移动先按上再按右。第一次dir_变上第二次按右右不是上的反向赋值成功dir_变右。下一帧蛇从向上直接转向向右——这其实还是合法的。真正致命的是这个顺序向右移动先按上再按下但因为某些实现里反向判断用的是蛇的实际移动方向而不是dir_变量就会出问题。更常见的坑是向右移动一帧内按上、右、下三步之后方向变成下而蛇刚从向右变成向上下一步直接从向上转成向下原地掉头撞上自己第二节。正确的解法是用队列并且反向判断基于队列末尾的方向void HandleDirection(Dir d) { if (state_ ! GameState::Running) return; Dir last pending_.empty() ? dir_ : pending_.back(); if (d last || IsOpposite(d, last)) return; // 基于最后一个待生效方向判断 if (pending_.size() 2) return; // 最多缓存两个防止乱按堆积 pending_.push_back(d); }然后在Step()里每一步从队列头取一个生效if (!pending_.empty()) { dir_ pending_.front(); pending_.pop_front(); }为什么队列长度限制是 2 而不是无限因为玩家的操作意图最多提前两步有意义。缓存太多会导致手指已经停了蛇还在按之前的指令拐弯的延迟感。限制成 2既能容纳快速的两连按比如绕过一字长蛇阵需要的两次转向又不会积累过多。IsOpposite的实现就是四组配对判断纯函数好测inline bool IsOpposite(Dir a, Dir b) { return (a Dir::Up b Dir::Down) || (a Dir::Down b Dir::Up) || (a Dir::Left b Dir::Right) || (a Dir::Right b Dir::Left); }3.3 碰撞检测与游戏结束判定每次Step()先算出新头坐标然后依次检查两个条件越界、撞自身。Point head NextHead(snake_.front(), dir_); // 按当前方向前进一格 // 1. 撞墙 if (head.x 0 || head.x kWidth || head.y 0 || head.y kHeight) { state_ GameState::Over; return; } // 2. 撞自身 —— 注意尾巴是否会被移走 bool willEat (head food_); size_t checkLen willEat ? snake_.size() : snake_.size() - 1; for (size_t i 0; i checkLen; i) { if (snake_[i] head) { state_ GameState::Over; return; } } // 3. 推进 snake_.push_front(head); if (willEat) { score_; SpawnFood(); } else { snake_.pop_back(); }第二步那个checkLen是有讲究的。如果这一步不吃食物尾巴会移走那么新头撞到当前尾巴的位置其实是合法的——蛇头追着蛇尾跑视觉上就是头贴尾但不重叠。但如果这一步要吃食物尾巴不移走那么撞尾巴就是真撞。很多实现直接写for (auto p : snake_) if (p head) die;把尾巴也算进去结果就是蛇长度到四节以上之后某些本来能过的弯过不去玩家会觉得明明没撞到怎么就死了。这个 bug 极其隐蔽因为只有贴尾操作才会触发测试的时候不容易复现。3.4 食物生成随机数怎么用才不出死循环最直觉的写法是这样的// 不推荐的写法 do { food_.x rand() % kWidth; food_.y rand() % kHeight; } while (IsOnSnake(food_));这段代码在蛇很长的时候会非常慢。假设蛇占了 590 个格子只剩 10 个空格那么每次命中空格的概率是 1/60期望循环次数 60 次尾部还有小概率跑到几百次。虽然最终会出来但会有一瞬间的卡顿。更糟糕的是如果蛇占满了全部格子这就是个死循环程序直接挂住。我的做法是先收集所有空格子再随机取下标void SpawnFood() { std::vectorPoint empty; empty.reserve(kWidth * kHeight - snake_.size()); for (int y 0; y kHeight; y) { for (int x 0; x kWidth; x) { Point p(x, y); if (std::find(snake_.begin(), snake_.end(), p) snake_.end()) empty.push_back(p); } } if (empty.empty()) { state_ GameState::Over; return; } // 蛇填满了通关 std::uniform_int_distributionsize_t dist(0, empty.size() - 1); food_ empty[dist(rng_)]; }时间复杂度是 O(格子数 × 蛇长)600 × 100 也就六万次比较现代 CPU 上不到一毫秒一局游戏总共调用几十次完全可以忽略。关键是它确定性不会卡死而且蛇填满地图时能正确地判定通关而不是挂住。随机引擎用std::mt19937不用rand()。原因有两个rand()的实现质量依赖标准库厂商某些平台上RAND_MAX只有 32767而且低位随机性差rand() % n这种取模方式在 n 不能整除RAND_MAX1时会产生分布偏差。std::uniform_int_distribution内部做了拒绝采样分布是平的。种子这里有个实际会遇到的问题Game() : rng_(std::random_device{}()) { Reset(); }在 MSVC 上std::random_device是真正的非确定性源没问题。但在某些 MinGW 版本上std::random_device是确定性实现内部固定种子结果就是每局游戏食物出现的位置序列完全一样。如果你跑起来发现怎么每次都吃到同一个地方八成就是这个。兜底方案是用时间播种auto seed static_castunsigned( std::chrono::steady_clock::now().time_since_epoch().count()); rng_.seed(seed);精度到纳秒两次启动撞种子的概率基本为零。3.5 跨平台按键读取Windows 与 Linux 两套实现控制台游戏必须解决怎么在不阻塞的情况下知道有没有按键这个问题。标准 C 没有提供只能走平台接口。Windows 侧很舒服conio.h里现成的#ifdef _WIN32 int ReadKey() { if (!_kbhit()) return -1; int c _getch(); if (c 0 || c 224) { // 功能键/方向键的双字节前缀 int code _getch(); switch (code) { case 72: return w; // 上 case 80: return s; // 下 case 75: return a; // 左 case 77: return d; // 右 } return -1; } return c; } #endif注意_getch()有个特性如果缓冲区里没有字符它会阻塞等待。所以必须先用_kbhit()判断。另外_getch()读方向键会返回两次第一次是 224或 0第二次才是具体扫描码——这个 224 前缀如果不处理方向键会失效。Linux 侧麻烦一些。终端默认是行缓冲 回显模式也就是你敲一个字符它不立刻给你要等回车而且敲什么屏幕上就显示什么。必须先改终端属性#ifndef _WIN32 #include termios.h #include unistd.h #include sys/select.h static termios g_oldTermios; static bool g_termiosSaved false; void InitConsole() { tcgetattr(STDIN_FILENO, g_oldTermios); g_termiosSaved true; termios raw g_oldTermios; raw.c_lflag ~(ICANON | ECHO); // 关行缓冲、关回显 raw.c_cc[VMIN] 0; // 非阻塞读 raw.c_cc[VTIME] 0; tcsetattr(STDIN_FILENO, TCSANOW, raw); std::fputs(\x1b[?25l, stdout); // 隐藏光标减少视觉干扰 } void RestoreConsole() { if (g_termiosSaved) tcsetattr(STDIN_FILENO, TCSANOW, g_oldTermios); std::fputs(\x1b[?25h, stdout); // 恢复光标 } int ReadKey() { fd_set set; FD_ZERO(set); FD_SET(STDIN_FILENO, set); timeval tv{0, 0}; if (select(STDIN_FILENO 1, set, nullptr, nullptr, tv) 0) return -1; unsigned char c 0; if (read(STDIN_FILENO, c, 1) ! 1) return -1; if (c 0x1b) { // ESC 开头的转义序列 unsigned char seq[2]; if (read(STDIN_FILENO, seq[0], 1) 1 read(STDIN_FILENO, seq[1], 1) 1) { if (seq[0] [) { switch (seq[1]) { case A: return w; case B: return s; case C: return d; case D: return a; } } } return 0x1b; // 单个 ESC当作退出 } return c; } #endif这里必须有个RestoreConsole()在main返回前、以及异常退出路径上调用。否则程序崩溃后你的终端会一直停留在无回显无行缓冲的状态敲命令看不见、必须按回车才执行很多人第一次遇到以为终端坏了其实是没恢复termios。用 RAII 包一层最稳struct ConsoleGuard { ConsoleGuard() { InitConsole(); } ~ConsoleGuard() { RestoreConsole(); } };这种构造时改全局状态、析构时改回去的写法是termios场景的标准做法比手动在main里写两行靠谱得多——至少异常栈展开时它也会执行。4. 动手实录从空文件到能跑起来的完整过程4.1 环境准备与编译命令代码是单文件的不依赖任何第三方库只要编译器支持 C11 就能编。三个平台的命令# Linux / macOSgcc 或 clang g -stdc11 -O2 -Wall -Wextra snake.cpp -o snake ./snake# macOS 如果默认是 clang同样写法C11 支持完整 clang -stdc11 -O2 -Wall snake.cpp -o snake:: Windows MSVC命令行 cl /EHsc /std:c14 /O2 snake.cpp /Fe:snake.exeMSVC 这里有个小坑它没有独立的/std:c11开关因为 MSVC 2015 之后直接跳到部分 C14/17 支持。写/std:c14就能覆盖我们要用的全部 C11 特性。另外/EHsc必须加否则标准库抛异常时会警告。如果用 CMake 管理会更清爽cmake_minimum_required(VERSION 3.10) project(snake CXX) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(snake snake.cpp)CMAKE_CXX_STANDARD_REQUIRED ON这行很重要。不加它的话如果编译器不支持 C11CMake 会静默降级到它支持的版本然后你在编译错误里找半天原因。4.2 关键代码骨架逐块拆解先说数据结构。这里有个 C11 专属的坑我在这上面浪费了半小时// 写法 AC11 下编译不过 struct Point { int x 0; int y 0; }; Point p{3, 5}; // error: no matching constructor原因是有默认成员初始化器的类在 C11 里不再是聚合类型aggregate花括号聚合初始化失效。C14 放宽了这个限制。所以在 C11 下要么去掉类内初始化器要么显式给构造函数。我选后者兼容性和可读性都更好struct Point { int x; int y; Point() : x(0), y(0) {} Point(int px, int py) : x(px), y(py) {} bool operator(const Point o) const { return x o.x y o.y; } };operator是必须的否则std::find没法用。注意参数是const Point函数本身是const成员函数——这两处漏一个都会编译报错报错信息还挺长新手容易懵。游戏类的骨架大致长这样我把能省的 getter 全省了渲染直接做成成员函数class Game { public: Game() : rng_(std::random_device{}()) { Reset(); } void Reset(); void HandleInput(int key); void Step(); void Draw(std::string out) const; bool Running() const { return state_ ! GameState::Over; } int StepMs() const; int Score() const { return score_; } private: void SpawnFood(); std::dequePoint snake_; std::dequeDir pending_; Point food_; Dir dir_ Dir::Right; GameState state_ GameState::Ready; int score_ 0; std::mt19937 rng_; };Reset()负责把蛇摆到中间偏左长度 3朝向右void Game::Reset() { snake_.clear(); int cx kWidth / 2, cy kHeight / 2; for (int i 0; i 3; i) snake_.push_back(Point(cx - i, cy)); // 头在最前所以 x 递减 dir_ Dir::Right; pending_.clear(); score_ 0; state_ GameState::Running; SpawnFood(); }注意这里的顺序push_back三次第一个推进去的是(cx, cy)它是头部因为它排在front()。后面两个(cx-1, cy)和(cx-2, cy)在它左边是身体。所以蛇头在右身体向左延伸朝向右——逻辑自洽。Step()就是前面 3.3 讲的那段HandleInput()是 3.2 那段SpawnFood()是 3.4 那段。三块拼起来逻辑层就完整了。4.3 渲染优化怎么让画面不闪闪烁的根源只有一个清屏和白画之间存在时间差中间那一瞬间屏幕是空的。system(cls)之所以闪得厉害一是它要 fork 一个子进程二是清完之后你要一行一行重新cout用户的眼睛能看到这个中间过程。解法是不清屏把光标移回左上角然后覆盖写。因为地图尺寸固定新画面的内容总会完整盖住旧画面不会留下残影。void CursorHome() { #ifdef _WIN32 static HANDLE h GetStdHandle(STD_OUTPUT_HANDLE); SetConsoleCursorPosition(h, COORD{0, 0}); #else std::fputs(\x1b[H, stdout); #endif }COORD{0, 0}这里能编译是因为COORD是纯聚合类型没有构造函数也没有类内初始化器。\x1b[H是 ANSI 的 CUP 序列H不带参数默认回 (1,1)。在此基础上还有一个更重要的优化把整帧拼成一个字符串一次输出。如果每画一个字符就cout c600 格就是 600 次函数调用加 600 次潜在的系统调用虽然标准库有缓冲但开销还是不小。拼好一次性fwrite一帧只有一次 I/Ovoid Game::Draw(std::string out) const { // 先把所有格子映射成字符避免输出时反复遍历蛇身 std::vectorchar grid(kWidth * kHeight, ); for (size_t i 0; i snake_.size(); i) { const Point p snake_[i]; if (p.x 0 || p.x kWidth || p.y 0 || p.y kHeight) continue; grid[p.y * kWidth p.x] (i 0) ? : o; } if (food_.x 0 food_.x kWidth food_.y 0 food_.y kHeight) grid[food_.y * kWidth food_.x] *; out.clear(); out ; out.append(kWidth * kCellChar, -); out \n; for (int y 0; y kHeight; y) { out |; for (int x 0; x kWidth; x) { char c grid[y * kWidth x]; out c; out ; // 每格补一个空格凑成 2 字符宽 } out |\n; } out ; out.append(kWidth * kCellChar, -); out \n; out Score: std::to_string(score_) Speed: std::to_string(StepMs()) ms\n; }grid这个中间数组是关键。不用它的话每判断一个格子就要遍历一遍蛇身600 × 100 六万次比较每帧都做一遍就有点浪费了。用数组做一次 O(蛇长) 的预处理之后每个格子的查询都是 O(1)。这属于典型的空间换时间代价只有 600 字节。out.reserve()也值得加预留容量避免反复扩容out.reserve((kWidth * kCellChar 3) * (kHeight 3) 64);调用侧CursorHome(); std::fwrite(buf.data(), 1, buf.size(), stdout); std::fflush(stdout);用fwrite而不是std::cout 是因为fwrite直接进 C 的缓冲区配合fflush时机可控。std::cout还要走一层sync_with_stdio的兼容层虽然可以关掉但用 C 接口更直接。4.4 用 C11 特性做一轮重构代码能跑之后我做了一轮回头整理主要是把 C 风格的部分换成 C11 惯用写法。对比一下典型的三处第一处方向定义。原来是#define UP 1加一堆宏改成enum class Dir { Up, Down, Left, Right }。好处前面说过命名不污染、类型安全。顺带一提switch里因为enum class不能被隐式转int写case Dir::Up:就行编译器还能帮你检查是不是漏了分支-Wswitch警告。第二处遍历。原来是for (int i 0; i len; i) if (snake[i].x ...)改成范围 forfor (const auto p : snake_) { if (p head) return true; }const auto里那个不能省。Point只有两个 int按值拷贝也不贵但养成引用遍历的习惯总是好的换成大结构体时不用改。const是防止在遍历中意外修改集合元素——虽然这里改成引用遍历后即使改了也不影响容器结构但语义上应该只读。第三处常量。原来一堆#define WIDTH 30改成constexpr int kWidth 30;。constexpr比const强的点是它能用在需要编译期常量的地方比如std::arraychar, kWidth * kHeight的模板参数、switch的case标签。而且它有类型调试器里能看到值宏在调试信息里是被展开掉的。顺带一个容易忽略的点如果把kWidth定义在类内部当静态成员class Game { static constexpr int kWidth 30; // C11 类内初始化 };C11 允许这样做但如果这个常量被 ODR-use 了比如取了地址、绑定了引用你还需要在类外给一个定义constexpr int Game::kWidth;不写的话在某些链接器上会报未定义符号。C17 的inline static解决了这个问题但 C11 就得手动补。我的做法是干脆不放类里直接放文件作用域的匿名命名空间省心namespace { constexpr int kWidth 30; constexpr int kHeight 20; constexpr int kBaseStepMs 180; constexpr int kMinStepMs 70; constexpr int kStepDecrementMs 15; constexpr int kFoodPerLevel 5; constexpr int kCellChar 2; }5. 排错实录那些年踩过的坑5.1 画面闪烁与按键丢失这两个症状经常一起出现但根因不同。闪烁基本都出在渲染方式上。三个检查点是不是还在用system(cls)是不是每个字符单独cout是不是每帧都cout endlendl会强制 flush每行刷一次一帧刷 21 次。改成光标归位 拼串 一次 fwrite闪烁基本消失。如果改完还闪那就不是代码问题是终端本身的刷新率。某些终端模拟器在大量输出时会明显掉帧试着把地图从 30×20 缩到 20×15 看看如果明显改善说明是终端扛不住。按键丢失只有一个原因主循环睡太久了。如果你的循环是Sleep(100)再检查一次_kbhit()那玩家在这 100 毫秒里按的所有键只有最后一个留在缓冲区里Windows 的键盘缓冲区其实能存多个但你的代码只读一次其它的就被折叠了。解法是主循环睡 1 毫秒每帧把缓冲区里的键全部读完int key ReadKey(); while (key ! -1) { game.HandleInput(key); key ReadKey(); }这个while很重要。配合 3.2 节的队列玩家快速按出的两个方向都能被记录下来操作手感会明显提升。5.2 蛇原地掉头直接判负前面 3.2 讲过了根因是反向判断的基准错了。但还有一种变体蛇长只有 2 的时候。初始长度如果是 2那么撞自身的判定里第二节就是尾巴而尾巴这一步会移走于是永远撞不到自己——看上去好像没问题。但如果你的判定排除了尾巴就没问题不排除的话长度 2 时玩家一转向就死。我用初始长度 3正好绕开这个边界情况同时视觉上蛇也像条蛇。还有一种更隐蔽的方向队列没清空。Reset()里如果只清了蛇身和分数忘了pending_.clear()重开一局时队列里可能残留上一局的方向蛇一开局就自己拐弯。这个 bug 只在死的时候恰好按了方向键时触发很难复现但确实存在。5.3 食物刷不出来程序卡死3.4 讲过的while随机法。补充一个更细的坑如果你用rand() % kWidth但忘了给srand播种每局的食物序列完全一样看起来不像是卡死而是怎么每次都吃到同一个地方。这个更像玄学问题实际上就是种子固定。还有个极端情况蛇快要填满整个地图时empty数组只剩几个格子如果这时候代码里有除零或者数组越界比如empty.size() - 1 
长河君 · 2026/10/27 22:34:17 · 阅读 1.2k C++11重写控制台贪吃蛇：帧循环、输入队列与渲染优化实战
控制台贪吃蛇这个题目我前前后后写过四遍。第一遍照着教程抄跑起来蛇会穿墙第二遍是给一个同学讲指针时现写的写完发现吃食物不长大第三遍用纯 C 重写卡在画面狂闪和按键被吞上第四遍用 C11 从头撸了一遍才终于把它当成一个正经小工程来对待。如果你手上正在做这个项目或者被留了这个作业、面试里要现场写一段那这篇基本就是我这几遍踩完坑之后的完整复盘。它不复杂一个文件、几百行代码就能跑但它几乎把控制台程序该遇到的坑都集齐了非阻塞输入、时间步长、渲染刷新、随机数、容器选型这些点随便拎一个出来都能聊很久。下面我按为什么这么设计—核心机制怎么实现—怎么一步步跑起来—出问题怎么查的顺序讲代码是比较完整地贴出来的能直接编译复现。1. 先想清楚一个控制台贪吃蛇到底在练什么1.1 三十分钟版本和能讲二十分钟的版本市面上流传的贪吃蛇代码九成是同一个路子一堆全局变量蛇身数组、长度、方向、食物坐标一个while(1)里先Sleep(200)再system(cls)清屏然后双重循环把整个地图重画一遍最后_kbhit()判断有没有按键。这种写法能跑但也仅限能跑。问题集中在三处system(cls)每帧调用一次外部进程闪烁肉眼可见Sleep的精度受系统调度影响越到后面越飘方向变量被直接赋值玩家手快连按两下就能让蛇原地掉头撞死自己。正经写一版需要解决的是另外几个问题输入和游戏逻辑解耦——按键只负责往队列里塞方向什么时候生效由逻辑层决定渲染和逻辑解耦——逻辑按固定步长推进渲染按屏幕刷新率跑两者不绑定时间用单调时钟累积——而不是靠Sleep的调用次数状态集中管理——一个GameState枚举顶掉一堆bool标志位。这四件事做完代码量其实没多多少但整个东西的性质变了从作业变成了小工程。这也是我推荐用 C11 重写的原因上面这四个问题C11 恰好都给了顺手的工具。std::chrono::steady_clock解决单调时钟std::deque解决蛇身头尾增删enum class解决方向枚举的命名污染和隐式转换std::mt19937解决随机数质量。用老写法硬凑也能凑出来但写起来别扭读起来更别扭。1.2 C11 在这个项目里的真实落点我不太喜欢那种为了用而用的写法比如硬塞一个std::shared_ptr进去。下面这张表是我实际用到的特性以及它们各自解决的具体问题不是罗列C11 特性在这个项目里的位置解决的实际问题enum class Dir方向定义避免UP/DOWN和别的常量撞名也禁止了int隐式转枚举std::chrono::steady_clock主循环计时不受系统时间调整影响比clock()和Sleep计数靠谱std::mt19937食物随机生成替代rand() % n的取模偏差周期足够长std::dequePoint蛇身存储头部插入、尾部删除都是 O(1)vector头部插入要整体搬移std::vectorPoint空格子收集食物生成时的一次性候选池随机取下标auto/ 范围 for遍历蛇身少写一堆迭代器类型名改容器类型时不用改遍历代码constexpr地图宽高、速度常量编译期确定数组大小可以用它类内成员初始化Point的坐标、游戏状态构造函数不用一个个写初始化列表nullptr指针初始化避免0和NULL的重载歧义std::to_string分数显示拼 HUD 字符串不用sprintf开缓冲区真正有含量的就前三行时钟、随机数、容器。剩下的属于顺手改善可读性。我一直觉得判断一个项目该不该用新特性标准很简单——用了之后代码是变短了还是变长了读的人是多花时间还是少花时间。按这个标准上面这些是划算的。1.3 技术选型为什么不上图形库、不引第三方库每次聊到控制台游戏总有人问为什么不用 SFML / SDL。我的答案很直接这个项目的重点是游戏循环和状态管理不是渲染。一旦引入图形库你的时间会花在窗口创建、纹理加载、事件循环适配、跨平台库配置上这些内容和贪吃蛇的核心逻辑一点关系都没有纯粹是噪音。同理ncurses这类终端控制库也不必要。它确实能省掉跨平台按键读取的麻烦但它会给你带来新的依赖而且它的窗口刷新模型对新手来说又是一层心智负担。我们需要的终端能力只有三样定位光标、读取单个按键、关闭行缓冲和回显。这三样东西Windows 是SetConsoleCursorPosition_kbhit/_getch 默认就好Linux 是 ANSI 转义序列 termiosselect加起来不到五十行条件编译。一个前置提醒控制台方案的天花板很低字符尺寸、颜色、动画都受限制。别在这儿追求画面好看把精力放在逻辑正确性和代码结构上那才是能带走的东西。2. 架构与数据模型动手前先画好这张图2.1 输入、逻辑、渲染三层分离整个程序我切成三块数据流向是单向的输入层每帧把键盘缓冲区里的所有按键全部取出交给游戏对象游戏对象只做一件事——往待处理方向队列里塞数据不直接改蛇头朝向。逻辑层按固定时间步长Step()每次推进一格内部完成方向生效、碰撞检测、吃食物判定、分数更新、食物重生。渲染层拿到当前游戏状态的快照拼一个长字符串一次性输出到终端。为什么要拆这么干净因为拆了之后每一层的问题都能独立定位。画面花了是渲染层的事蛇走位怪是逻辑层的事按键没响应是输入层的事。混在一起的代码出了问题你只能全局猜。而且分层之后有个额外好处逻辑层完全不碰任何 I/O这意味着你可以写单元测试——比如构造一个场景调十次Step()断言蛇头坐标和游戏状态。控制台程序也能量测试这一点很多人没意识到。2.2 蛇身容器选型std::deque 还是 std::vector这是这个项目里最值得聊的一个选型。蛇的移动本质是头部新增一节尾部删掉一节吃了食物则尾部不删。也就是头插尾删。三种候选方案对比容器头部插入尾部删除随机访问内存连续性结论std::vectorO(n)整体搬移O(1)支持连续蛇长几十节时开销可忽略但语义别扭std::dequeO(1)O(1)支持分段连续首选语义和操作复杂度都匹配std::listO(1)O(1)不支持节点分散判重用不了随机访问反而更慢蛇长最多也就几百节vector的头插开销其实完全扛得住但用deque的理由不只是性能是语义匹配。代码里push_front和pop_back写出来任何人扫一眼就知道这是队列结构用vector配合insert(begin(), ...)和pop_back()读代码的人会下意识觉得这里是不是写错了。另外避免用list因为碰撞检测需要遍历蛇身判断某个坐标是否被占据list的缓存不友好而且没有下标访问会逼你写一堆迭代器。约定上我选蛇头在front()。这样snake_.front()永远是当前头snake_.back()永远是尾。也有代码把头放back()也不是不行但每次取头都要back()读起来反直觉。2.3 网格坐标系与尺寸参数怎么定地图定成 30 列 × 20 行也就是 600 个格子。这个数字不是拍脑袋定的常见终端窗口宽度是 80 字符扣掉边框和边距留给游戏区的大约 60 字符而终端字符的宽高比大概是 1:2也就是一个字符宽约等于半个字符高。所以每个格子横向占两个字符宽度30 格 × 2 60 字符宽20 格 × 1 字符高 20 行画出来视觉上正好接近正方形。如果每格只输出一个字符你会得到一个扁扁的、横向拉伸的地图蛇的移动速度看起来上下快、左右慢——因为同样是一格位移横向看着短、纵向看着长。这个细节很多人不注意第一次做出来的版本总感觉手感不对八成就是这个原因。constexpr int kWidth 30; // 横向格子数 constexpr int kHeight 20; // 纵向格子数 constexpr int kCellChar 2; // 每格占用字符宽度用于修正终端字符宽高比坐标系我选左上角为原点 (0,0)x 向右增y 向下增。这样和终端光标的行列方向一致渲染的时候不用做任何翻转是个纯粹的偷懒决定但确实能省掉一堆kHeight - 1 - y的换算。2.4 状态机四种状态跑完整个生命周期游戏状态我定义为四个Ready还没开始、Running进行中、Paused暂停、Over结束。用enum class定义enum class GameState { Ready, Running, Paused, Over };用enum class而不是普通enum最实际的原因是普通枚举的成员会泄漏到外层作用域。你定义enum { Over, Paused }那Over就变成了全局可见的标识符很容易和别的东西撞名。enum class强制写成GameState::Over而且不允许隐式转成intif (state 3)这种写法直接编译不过——这算是一种保护。状态迁移的规则很简单但必须写死不能散落各处Ready收到任意移动键 →RunningRunning按下暂停键 →Paused再按一次 →RunningRunning撞墙或撞自己 →OverOver按下重开键 → 重置所有数据回Ready状态迁移集中处理的好处是你不用在每个函数开头写一堆if (paused) return;。只有Step()和输入处理需要检查状态其余函数无脑执行。3. 核心机制的实现细节3.1 帧循环与时间步长把速度变成可调参数Sleep(200)这种做法最大的问题是它把游戏速度和主循环节奏绑死了。想让蛇加速你得改睡眠时长想让画面刷新更流畅又得改睡眠时长——两个需求打架。正确做法是用累加器模式主循环以极高频率空转每圈睡 1 毫秒同时用单调时钟测量真实流逝的时间把流逝的时间累加到一个变量里只要累加值超过当前步长就推进一次逻辑并把累加值减去步长。auto last std::chrono::steady_clock::now(); int64_t acc 0; while (game.Running()) { auto now std::chrono::steady_clock::now(); int64_t dt std::chrono::duration_caststd::chrono::milliseconds(now - last).count(); last now; if (dt 250) dt 250; // 关键钳制单帧最大时间 acc dt; int stepMs game.StepMs(); while (acc stepMs) { game.Step(); acc - stepMs; stepMs game.StepMs(); // 吃掉食物后步长可能变化要重取 } Render(game); std::this_thread::sleep_for(std::chrono::milliseconds(1)); }这里有两个细节都是踩过坑才加上的。第一个是dt钳制。如果不加用户把窗口切走十秒钟再切回来dt就是 10000累加器瞬间攒够几十步游戏会在几毫秒内疯狂推进几十格蛇直接飞出地图。钳制到 250 毫秒最多补跑一两步视觉上就是卡了一下不会崩。第二个是内层while里重新取stepMs。因为蛇吃到食物后速度档位可能提升步长变小。如果只在循环外用一次stepMs加速会延迟一帧生效虽然影响极小但逻辑上不干净。速度曲线我这么设计基础步长 180 毫秒每吃 5 个食物提升一档每档减 15 毫秒下限 70 毫秒。int StepMs() const { int level score_ / kFoodPerLevel; // kFoodPerLevel 5 int ms kBaseStepMs - level * kStepDecrementMs; // 180 - level * 15 return ms kMinStepMs ? kMinStepMs : ms; }算一下0 到 4 分是 180ms5 到 9 分是 165ms10 到 14 分是 150ms……到 40 分时按公式是 180 - 8×15 60ms已经低于下限被封在 70ms。也就是说 40 分之后速度不再变化。下限 70ms 的理由很实在再快的话普通人眼和手指就跟不上了而且主循环每圈睡 1ms70ms 一步大概能分到 70 帧渲染不撕裂。低于 50ms 人就基本没法玩了那是给机器玩的。3.2 转向输入队列解决一帧内连按三个方向自杀的经典坑这是新手代码里最高频的 bug值得单独展开。假设蛇向右移动玩家手快在一帧之内依次按了上和下。如果代码是直接赋值// 错误写法 if (!IsOpposite(newDir, dir_)) dir_ newDir;第一次按上dir_是右上不是右的反向赋值成功dir_变成上。第二次按下此时dir_已经是上下是上的反向会被拒绝——这个分支恰好挡住了。但换个顺序就翻车向右移动先按上再按右。第一次dir_变上第二次按右右不是上的反向赋值成功dir_变右。下一帧蛇从向上直接转向向右——这其实还是合法的。真正致命的是这个顺序向右移动先按上再按下但因为某些实现里反向判断用的是蛇的实际移动方向而不是dir_变量就会出问题。更常见的坑是向右移动一帧内按上、右、下三步之后方向变成下而蛇刚从向右变成向上下一步直接从向上转成向下原地掉头撞上自己第二节。正确的解法是用队列并且反向判断基于队列末尾的方向void HandleDirection(Dir d) { if (state_ ! GameState::Running) return; Dir last pending_.empty() ? dir_ : pending_.back(); if (d last || IsOpposite(d, last)) return; // 基于最后一个待生效方向判断 if (pending_.size() 2) return; // 最多缓存两个防止乱按堆积 pending_.push_back(d); }然后在Step()里每一步从队列头取一个生效if (!pending_.empty()) { dir_ pending_.front(); pending_.pop_front(); }为什么队列长度限制是 2 而不是无限因为玩家的操作意图最多提前两步有意义。缓存太多会导致手指已经停了蛇还在按之前的指令拐弯的延迟感。限制成 2既能容纳快速的两连按比如绕过一字长蛇阵需要的两次转向又不会积累过多。IsOpposite的实现就是四组配对判断纯函数好测inline bool IsOpposite(Dir a, Dir b) { return (a Dir::Up b Dir::Down) || (a Dir::Down b Dir::Up) || (a Dir::Left b Dir::Right) || (a Dir::Right b Dir::Left); }3.3 碰撞检测与游戏结束判定每次Step()先算出新头坐标然后依次检查两个条件越界、撞自身。Point head NextHead(snake_.front(), dir_); // 按当前方向前进一格 // 1. 撞墙 if (head.x 0 || head.x kWidth || head.y 0 || head.y kHeight) { state_ GameState::Over; return; } // 2. 撞自身 —— 注意尾巴是否会被移走 bool willEat (head food_); size_t checkLen willEat ? snake_.size() : snake_.size() - 1; for (size_t i 0; i checkLen; i) { if (snake_[i] head) { state_ GameState::Over; return; } } // 3. 推进 snake_.push_front(head); if (willEat) { score_; SpawnFood(); } else { snake_.pop_back(); }第二步那个checkLen是有讲究的。如果这一步不吃食物尾巴会移走那么新头撞到当前尾巴的位置其实是合法的——蛇头追着蛇尾跑视觉上就是头贴尾但不重叠。但如果这一步要吃食物尾巴不移走那么撞尾巴就是真撞。很多实现直接写for (auto p : snake_) if (p head) die;把尾巴也算进去结果就是蛇长度到四节以上之后某些本来能过的弯过不去玩家会觉得明明没撞到怎么就死了。这个 bug 极其隐蔽因为只有贴尾操作才会触发测试的时候不容易复现。3.4 食物生成随机数怎么用才不出死循环最直觉的写法是这样的// 不推荐的写法 do { food_.x rand() % kWidth; food_.y rand() % kHeight; } while (IsOnSnake(food_));这段代码在蛇很长的时候会非常慢。假设蛇占了 590 个格子只剩 10 个空格那么每次命中空格的概率是 1/60期望循环次数 60 次尾部还有小概率跑到几百次。虽然最终会出来但会有一瞬间的卡顿。更糟糕的是如果蛇占满了全部格子这就是个死循环程序直接挂住。我的做法是先收集所有空格子再随机取下标void SpawnFood() { std::vectorPoint empty; empty.reserve(kWidth * kHeight - snake_.size()); for (int y 0; y kHeight; y) { for (int x 0; x kWidth; x) { Point p(x, y); if (std::find(snake_.begin(), snake_.end(), p) snake_.end()) empty.push_back(p); } } if (empty.empty()) { state_ GameState::Over; return; } // 蛇填满了通关 std::uniform_int_distributionsize_t dist(0, empty.size() - 1); food_ empty[dist(rng_)]; }时间复杂度是 O(格子数 × 蛇长)600 × 100 也就六万次比较现代 CPU 上不到一毫秒一局游戏总共调用几十次完全可以忽略。关键是它确定性不会卡死而且蛇填满地图时能正确地判定通关而不是挂住。随机引擎用std::mt19937不用rand()。原因有两个rand()的实现质量依赖标准库厂商某些平台上RAND_MAX只有 32767而且低位随机性差rand() % n这种取模方式在 n 不能整除RAND_MAX1时会产生分布偏差。std::uniform_int_distribution内部做了拒绝采样分布是平的。种子这里有个实际会遇到的问题Game() : rng_(std::random_device{}()) { Reset(); }在 MSVC 上std::random_device是真正的非确定性源没问题。但在某些 MinGW 版本上std::random_device是确定性实现内部固定种子结果就是每局游戏食物出现的位置序列完全一样。如果你跑起来发现怎么每次都吃到同一个地方八成就是这个。兜底方案是用时间播种auto seed static_castunsigned( std::chrono::steady_clock::now().time_since_epoch().count()); rng_.seed(seed);精度到纳秒两次启动撞种子的概率基本为零。3.5 跨平台按键读取Windows 与 Linux 两套实现控制台游戏必须解决怎么在不阻塞的情况下知道有没有按键这个问题。标准 C 没有提供只能走平台接口。Windows 侧很舒服conio.h里现成的#ifdef _WIN32 int ReadKey() { if (!_kbhit()) return -1; int c _getch(); if (c 0 || c 224) { // 功能键/方向键的双字节前缀 int code _getch(); switch (code) { case 72: return w; // 上 case 80: return s; // 下 case 75: return a; // 左 case 77: return d; // 右 } return -1; } return c; } #endif注意_getch()有个特性如果缓冲区里没有字符它会阻塞等待。所以必须先用_kbhit()判断。另外_getch()读方向键会返回两次第一次是 224或 0第二次才是具体扫描码——这个 224 前缀如果不处理方向键会失效。Linux 侧麻烦一些。终端默认是行缓冲 回显模式也就是你敲一个字符它不立刻给你要等回车而且敲什么屏幕上就显示什么。必须先改终端属性#ifndef _WIN32 #include termios.h #include unistd.h #include sys/select.h static termios g_oldTermios; static bool g_termiosSaved false; void InitConsole() { tcgetattr(STDIN_FILENO, g_oldTermios); g_termiosSaved true; termios raw g_oldTermios; raw.c_lflag ~(ICANON | ECHO); // 关行缓冲、关回显 raw.c_cc[VMIN] 0; // 非阻塞读 raw.c_cc[VTIME] 0; tcsetattr(STDIN_FILENO, TCSANOW, raw); std::fputs(\x1b[?25l, stdout); // 隐藏光标减少视觉干扰 } void RestoreConsole() { if (g_termiosSaved) tcsetattr(STDIN_FILENO, TCSANOW, g_oldTermios); std::fputs(\x1b[?25h, stdout); // 恢复光标 } int ReadKey() { fd_set set; FD_ZERO(set); FD_SET(STDIN_FILENO, set); timeval tv{0, 0}; if (select(STDIN_FILENO 1, set, nullptr, nullptr, tv) 0) return -1; unsigned char c 0; if (read(STDIN_FILENO, c, 1) ! 1) return -1; if (c 0x1b) { // ESC 开头的转义序列 unsigned char seq[2]; if (read(STDIN_FILENO, seq[0], 1) 1 read(STDIN_FILENO, seq[1], 1) 1) { if (seq[0] [) { switch (seq[1]) { case A: return w; case B: return s; case C: return d; case D: return a; } } } return 0x1b; // 单个 ESC当作退出 } return c; } #endif这里必须有个RestoreConsole()在main返回前、以及异常退出路径上调用。否则程序崩溃后你的终端会一直停留在无回显无行缓冲的状态敲命令看不见、必须按回车才执行很多人第一次遇到以为终端坏了其实是没恢复termios。用 RAII 包一层最稳struct ConsoleGuard { ConsoleGuard() { InitConsole(); } ~ConsoleGuard() { RestoreConsole(); } };这种构造时改全局状态、析构时改回去的写法是termios场景的标准做法比手动在main里写两行靠谱得多——至少异常栈展开时它也会执行。4. 动手实录从空文件到能跑起来的完整过程4.1 环境准备与编译命令代码是单文件的不依赖任何第三方库只要编译器支持 C11 就能编。三个平台的命令# Linux / macOSgcc 或 clang g -stdc11 -O2 -Wall -Wextra snake.cpp -o snake ./snake# macOS 如果默认是 clang同样写法C11 支持完整 clang -stdc11 -O2 -Wall snake.cpp -o snake:: Windows MSVC命令行 cl /EHsc /std:c14 /O2 snake.cpp /Fe:snake.exeMSVC 这里有个小坑它没有独立的/std:c11开关因为 MSVC 2015 之后直接跳到部分 C14/17 支持。写/std:c14就能覆盖我们要用的全部 C11 特性。另外/EHsc必须加否则标准库抛异常时会警告。如果用 CMake 管理会更清爽cmake_minimum_required(VERSION 3.10) project(snake CXX) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(snake snake.cpp)CMAKE_CXX_STANDARD_REQUIRED ON这行很重要。不加它的话如果编译器不支持 C11CMake 会静默降级到它支持的版本然后你在编译错误里找半天原因。4.2 关键代码骨架逐块拆解先说数据结构。这里有个 C11 专属的坑我在这上面浪费了半小时// 写法 AC11 下编译不过 struct Point { int x 0; int y 0; }; Point p{3, 5}; // error: no matching constructor原因是有默认成员初始化器的类在 C11 里不再是聚合类型aggregate花括号聚合初始化失效。C14 放宽了这个限制。所以在 C11 下要么去掉类内初始化器要么显式给构造函数。我选后者兼容性和可读性都更好struct Point { int x; int y; Point() : x(0), y(0) {} Point(int px, int py) : x(px), y(py) {} bool operator(const Point o) const { return x o.x y o.y; } };operator是必须的否则std::find没法用。注意参数是const Point函数本身是const成员函数——这两处漏一个都会编译报错报错信息还挺长新手容易懵。游戏类的骨架大致长这样我把能省的 getter 全省了渲染直接做成成员函数class Game { public: Game() : rng_(std::random_device{}()) { Reset(); } void Reset(); void HandleInput(int key); void Step(); void Draw(std::string out) const; bool Running() const { return state_ ! GameState::Over; } int StepMs() const; int Score() const { return score_; } private: void SpawnFood(); std::dequePoint snake_; std::dequeDir pending_; Point food_; Dir dir_ Dir::Right; GameState state_ GameState::Ready; int score_ 0; std::mt19937 rng_; };Reset()负责把蛇摆到中间偏左长度 3朝向右void Game::Reset() { snake_.clear(); int cx kWidth / 2, cy kHeight / 2; for (int i 0; i 3; i) snake_.push_back(Point(cx - i, cy)); // 头在最前所以 x 递减 dir_ Dir::Right; pending_.clear(); score_ 0; state_ GameState::Running; SpawnFood(); }注意这里的顺序push_back三次第一个推进去的是(cx, cy)它是头部因为它排在front()。后面两个(cx-1, cy)和(cx-2, cy)在它左边是身体。所以蛇头在右身体向左延伸朝向右——逻辑自洽。Step()就是前面 3.3 讲的那段HandleInput()是 3.2 那段SpawnFood()是 3.4 那段。三块拼起来逻辑层就完整了。4.3 渲染优化怎么让画面不闪闪烁的根源只有一个清屏和白画之间存在时间差中间那一瞬间屏幕是空的。system(cls)之所以闪得厉害一是它要 fork 一个子进程二是清完之后你要一行一行重新cout用户的眼睛能看到这个中间过程。解法是不清屏把光标移回左上角然后覆盖写。因为地图尺寸固定新画面的内容总会完整盖住旧画面不会留下残影。void CursorHome() { #ifdef _WIN32 static HANDLE h GetStdHandle(STD_OUTPUT_HANDLE); SetConsoleCursorPosition(h, COORD{0, 0}); #else std::fputs(\x1b[H, stdout); #endif }COORD{0, 0}这里能编译是因为COORD是纯聚合类型没有构造函数也没有类内初始化器。\x1b[H是 ANSI 的 CUP 序列H不带参数默认回 (1,1)。在此基础上还有一个更重要的优化把整帧拼成一个字符串一次输出。如果每画一个字符就cout c600 格就是 600 次函数调用加 600 次潜在的系统调用虽然标准库有缓冲但开销还是不小。拼好一次性fwrite一帧只有一次 I/Ovoid Game::Draw(std::string out) const { // 先把所有格子映射成字符避免输出时反复遍历蛇身 std::vectorchar grid(kWidth * kHeight, ); for (size_t i 0; i snake_.size(); i) { const Point p snake_[i]; if (p.x 0 || p.x kWidth || p.y 0 || p.y kHeight) continue; grid[p.y * kWidth p.x] (i 0) ? : o; } if (food_.x 0 food_.x kWidth food_.y 0 food_.y kHeight) grid[food_.y * kWidth food_.x] *; out.clear(); out ; out.append(kWidth * kCellChar, -); out \n; for (int y 0; y kHeight; y) { out |; for (int x 0; x kWidth; x) { char c grid[y * kWidth x]; out c; out ; // 每格补一个空格凑成 2 字符宽 } out |\n; } out ; out.append(kWidth * kCellChar, -); out \n; out Score: std::to_string(score_) Speed: std::to_string(StepMs()) ms\n; }grid这个中间数组是关键。不用它的话每判断一个格子就要遍历一遍蛇身600 × 100 六万次比较每帧都做一遍就有点浪费了。用数组做一次 O(蛇长) 的预处理之后每个格子的查询都是 O(1)。这属于典型的空间换时间代价只有 600 字节。out.reserve()也值得加预留容量避免反复扩容out.reserve((kWidth * kCellChar 3) * (kHeight 3) 64);调用侧CursorHome(); std::fwrite(buf.data(), 1, buf.size(), stdout); std::fflush(stdout);用fwrite而不是std::cout 是因为fwrite直接进 C 的缓冲区配合fflush时机可控。std::cout还要走一层sync_with_stdio的兼容层虽然可以关掉但用 C 接口更直接。4.4 用 C11 特性做一轮重构代码能跑之后我做了一轮回头整理主要是把 C 风格的部分换成 C11 惯用写法。对比一下典型的三处第一处方向定义。原来是#define UP 1加一堆宏改成enum class Dir { Up, Down, Left, Right }。好处前面说过命名不污染、类型安全。顺带一提switch里因为enum class不能被隐式转int写case Dir::Up:就行编译器还能帮你检查是不是漏了分支-Wswitch警告。第二处遍历。原来是for (int i 0; i len; i) if (snake[i].x ...)改成范围 forfor (const auto p : snake_) { if (p head) return true; }const auto里那个不能省。Point只有两个 int按值拷贝也不贵但养成引用遍历的习惯总是好的换成大结构体时不用改。const是防止在遍历中意外修改集合元素——虽然这里改成引用遍历后即使改了也不影响容器结构但语义上应该只读。第三处常量。原来一堆#define WIDTH 30改成constexpr int kWidth 30;。constexpr比const强的点是它能用在需要编译期常量的地方比如std::arraychar, kWidth * kHeight的模板参数、switch的case标签。而且它有类型调试器里能看到值宏在调试信息里是被展开掉的。顺带一个容易忽略的点如果把kWidth定义在类内部当静态成员class Game { static constexpr int kWidth 30; // C11 类内初始化 };C11 允许这样做但如果这个常量被 ODR-use 了比如取了地址、绑定了引用你还需要在类外给一个定义constexpr int Game::kWidth;不写的话在某些链接器上会报未定义符号。C17 的inline static解决了这个问题但 C11 就得手动补。我的做法是干脆不放类里直接放文件作用域的匿名命名空间省心namespace { constexpr int kWidth 30; constexpr int kHeight 20; constexpr int kBaseStepMs 180; constexpr int kMinStepMs 70; constexpr int kStepDecrementMs 15; constexpr int kFoodPerLevel 5; constexpr int kCellChar 2; }5. 排错实录那些年踩过的坑5.1 画面闪烁与按键丢失这两个症状经常一起出现但根因不同。闪烁基本都出在渲染方式上。三个检查点是不是还在用system(cls)是不是每个字符单独cout是不是每帧都cout endlendl会强制 flush每行刷一次一帧刷 21 次。改成光标归位 拼串 一次 fwrite闪烁基本消失。如果改完还闪那就不是代码问题是终端本身的刷新率。某些终端模拟器在大量输出时会明显掉帧试着把地图从 30×20 缩到 20×15 看看如果明显改善说明是终端扛不住。按键丢失只有一个原因主循环睡太久了。如果你的循环是Sleep(100)再检查一次_kbhit()那玩家在这 100 毫秒里按的所有键只有最后一个留在缓冲区里Windows 的键盘缓冲区其实能存多个但你的代码只读一次其它的就被折叠了。解法是主循环睡 1 毫秒每帧把缓冲区里的键全部读完int key ReadKey(); while (key ! -1) { game.HandleInput(key); key ReadKey(); }这个while很重要。配合 3.2 节的队列玩家快速按出的两个方向都能被记录下来操作手感会明显提升。5.2 蛇原地掉头直接判负前面 3.2 讲过了根因是反向判断的基准错了。但还有一种变体蛇长只有 2 的时候。初始长度如果是 2那么撞自身的判定里第二节就是尾巴而尾巴这一步会移走于是永远撞不到自己——看上去好像没问题。但如果你的判定排除了尾巴就没问题不排除的话长度 2 时玩家一转向就死。我用初始长度 3正好绕开这个边界情况同时视觉上蛇也像条蛇。还有一种更隐蔽的方向队列没清空。Reset()里如果只清了蛇身和分数忘了pending_.clear()重开一局时队列里可能残留上一局的方向蛇一开局就自己拐弯。这个 bug 只在死的时候恰好按了方向键时触发很难复现但确实存在。5.3 食物刷不出来程序卡死3.4 讲过的while随机法。补充一个更细的坑如果你用rand() % kWidth但忘了给srand播种每局的食物序列完全一样看起来不像是卡死而是怎么每次都吃到同一个地方。这个更像玄学问题实际上就是种子固定。还有个极端情况蛇快要填满整个地图时empty数组只剩几个格子如果这时候代码里有除零或者数组越界比如empty.size() - 1