简介：这是一份基于MFC框架实现的经典扫雷游戏完整项目，面向学习Windows界面编程和游戏逻辑的C++初学者，也可作为课程设计或毕业设计的参考范例。项目通过对话框和自定义按钮控件，完整实现了雷区随机生成、左键翻开、右键标记、计时统计等核心玩法，并配套源码可直接编译运行。压缩包共71个文件，含26个bmp位图资源、8个h头文件、7个cpp源文件及1个exe可执行程序，另有dll、ico、rc、dsp/dsw工程文件等，整体约2.7MB，结构清晰，便于对照阅读和二次开发。源码中CMyDialog与CMyButton的协作方式，能直观展示MFC消息映射机制和自定义控件开发思路，适合需要借助完整实例快速上手MFC开发的学习者。资源已获得474人学习关注，是理解Windows程序框架与交互逻辑的不错入口。 很多人初学 Windows 桌面开发，拿到 MFC 之后第一反应是懵：类名多、消息机制绕、界面画起来也费劲，教材里的栗子不是"Hello World"就是"单文档画直线"，学完依旧不知道这玩意儿到底能干嘛。我自己带过的几个新同事也是如此，直到我建议他们用 MFC 完整写一个扫雷游戏，情况才有了质变。
为什么选扫雷？这个游戏规则极简，但技术上覆盖了窗口绘制、鼠标消息处理、定时器、随机数、状态机、甚至简单的资源管理，几乎把 MFC 做小工具需要的东西全部过了一遍。而且它天然自带反馈：你写错了，游戏肯定玩不通，驱动你回去改 bug 的动力比任何练习题都强。这篇文章就从零到一，把我实际写这个程序时踩过的坑、做过的选型、想过的设计全部摊开讲，不需要你有多深的 MFC 基础，对着做就行。
1. 为什么值得用 MFC 把扫雷完整写一遍：项目选型与准备工作
1.1 这个项目背后真正的学习价值
很多教程喜欢拿 MFC 做图书管理、学生信息管理这类 CRUD 程序，但说实话，那些项目对 MFC 的底层机制挖掘很浅，反而对数据库操作、列表控件更上心。扫雷游戏的逻辑里几乎没有数据库和业务表单，它逼着你直面三件事：
第一，窗口怎么响应鼠标。左键翻开、右键标旗、双击联动，这些操作在人看来很自然，但放到 MFC 的消息路由里，你要清楚 WM_LBUTTONDOWN、WM_RBUTTONDOWN 在视图类、框架类之间怎么流转，怎么在坐标上来回换算。这一步没走顺，后面就谈不上交互。
第二，视图重绘是怎么工作的。扫雷的画面是动态的，每点开一块都要重新画。MFC 里 Invalidate 和 OnDraw 的关系，GDI 画矩形画位图的逻辑，双缓冲解决闪烁的技巧，都会在这个项目里全部用到，而且想躲都躲不掉。
第三，程序状态的表达。游戏看起来只是在翻格子，但背后是"正在游戏、胜利、失败"这些大状态，以及每块格子"已翻开、已标记、未翻开"的小状态。不把状态管理清楚，短短几百行代码就能烂成一团。
我自己带新人的时候，通常让他们先抛弃向导生成的文档视图结构，直接用 MFC 对话框或单文档框架写一个纯视图交互的程序，扫雷刚好是标准范本。它适合所有对 C++ 有一定了解、想深入 Windows 原生开发、但又不想一上来啃 Win32 API 的读者。
1.2 开发环境与工程创建
我使用的环境是 Visual Studio 2019，选用 "MFC 应用程序" 项目模板，在向导里把应用程序类型设置成"单个文档"，把"文档/视图体系结构支持"去掉，或者干脆选择基于对话框的工程。两种都可以，我更推荐去掉文档视图的 SDI 工程，因为它直接把你丢进一个全屏视图类里，空间够大，代码也简单。
一个容易被忽略的点是字符集选项。我在实际项目里见过太多同事在这个地方踩坑，后面我会专门用一个小节讲。现阶段创建项目时，建议在向导的"高级功能"页里保持默认，字符集选"使用 Unicode 字符集"也没问题，但你要知道它和你写字符串字面量时的关系。
工程建好后，你会得到一个继承自 CView 的类和一个继承自 CFrameWnd 的框架类。我的建议是，把游戏的全部逻辑和绘制都放在视图类里，框架类只负责创建窗口、设置标题、处理菜单响应，这样才能让结构清晰、方便调试。
2. 雷区是怎么"想"出来的：数据结构与布雷算法
2.1 用一张表把玩家看到的和程序记住的关联起来
扫雷界面上是一个 n 行 m 列的格子矩阵，程序内部绝不能跟着界面走，界面只是状态的可视化投射。我的做法是定义两个二维数组，一层管逻辑，一层管显示。
const int ROWS = 9; // 初级 9x9 const int COLS = 9; const int MINE_COUNT = 10; // 逻辑层：记录地雷分布，用 -1 表示雷，0~8 表示周围雷数 int mineMap[ROWS][COLS]; // 显示层：记录每格可见状态 // 0 - 未翻开 // 1 - 已翻开 // 2 - 已插旗 // 3 - 已标记问号（可选） int dispMap[ROWS][COLS];有人可能会问，为什么不用一个结构体把两个状态打包在一起？完全可以，但在小规模项目里，分开两个数组在遍历时更直接、缓存更友好，而且读代码的人一眼就能明白每层数据的职责。这个分离的思想，比数组本身更重要。
2.2 布雷算法的两个核心约束
布雷本身不复杂，随机出坐标、放置地雷就行。但扫雷玩家默认有一条潜规则：第一次点击绝不能踩雷。实现方式有两种。
第一种是先用随机数布雷，玩家第一次点击后，如果踩到雷就移动这颗雷；第二种是玩家点完第一下之后，把第一格附近的格子排除在外再开始布雷。我推荐第二种实现，因为它逻辑上更安全，不会出现"移雷"时其他格子数字更新不及时的问题。
固定随机数种子的问题也要注意。C 语言里rand()和srand()的组合在 Windows 上有个经典毛病：如果每次重新开局都用srand(time(NULL))，可能会出现"每局第一排雷位置总一样"或者随机性差强人意的情况。我习惯使用 C++11 的<random>库，用random_device生成种子，mt19937作为随机引擎，分布用uniform_int_distribution，这样随机质量好得多，写起来也没多几行代码。
还有一件事：布雷必须发生在数字填充之前。如果先填数字再布雷，就得在布雷时再去更新周围格子的数字，逻辑串在一起会很难查错。我把这两个阶段拆成独立的函数，每个函数只做一件事。
void CMineSweeperView::InitMineMap(int excludeRow, int excludeCol) { // 1. 全部置 0 memset(mineMap, 0, sizeof(mineMap)); // 2. 收集非首点区域的合法格子，再从中抽取 MINE_COUNT 个布雷 std::vector<std::pair<int,int>> candidates; for (int r = 0; r < ROWS; r++) for (int c = 0; c < COLS; c++) if (abs(r - excludeRow) > 1 || abs(c - excludeCol) > 1) candidates.push_back({r, c}); std::shuffle(candidates.begin(), candidates.end(), rng); for (int i = 0; i < MINE_COUNT; i++) mineMap[candidates[i].first][candidates[i].second] = -1; // 3. 填充数字格 for (int r = 0; r < ROWS; r++) for (int c = 0; c < COLS; c++) if (mineMap[r][c] != -1) mineMap[r][c] = CountAdjacentMines(r, c); }这里把首次点击位置周围 8 格也一起排除在外，保证"翻开一片"的前几次交互体验很干净。手工扫雷的老玩家都知道，开局最好点出一片空白才舒服。
2.3 数字填充的技术细节
数字填充逻辑是一个双层循环，对每个非雷格子检查它周围 8 个位置里有多少个雷。这里容易犯的错是数组越界，尤其边缘格子（比如 (0,0)）访问 (-1,-1) 就会直接崩。
两种常见写法：一种是在循环里加边界判断；另一种是给数组整体加一圈"哨兵"填充，把数组定义为[ROWS+2][COLS+2]，四周边界全部设成一个特殊值，比如 0 或一个不会干扰统计的数，然后只遍历内部的 1~ROWS、1~COLS。第二种写法写起来更干净，统计函数可以完全不管边界判断，我比较推荐。
int CMineSweeperView::CountAdjacentMines(int r, int c) { int cnt = 0; for (int dr = -1; dr <= 1; dr++) for (int dc = -1; dc <= 1; dc++) if (mineMap[r+dr][c+dc] == -1) cnt++; return cnt; }前提是你一定要保证周圈的哨兵位置永远不是雷，初始化时需要把数组整个清干净，并且布雷的范围限制在 1~ROWS、1~COLS 内部。
3. 界面上那一块块格子怎么画：从 CButton 到自绘视图
3.1 新手最顺手的方案：CButton 数组，但坑不少
我看过不少初版扫雷代码，用的都是CButton对象数组，每个格子放一个按钮，然后动态创建一个 9x9 的按钮网格。这样写的好处很明显：你不必处理鼠标坐标换算，按钮的消息响应自带格子的身份信息，重绘时调SetWindowText改文字就行。
但它的坏处也相当明显。第一，按钮默认有系统绘制样式，想要那种"方块凸起，按下去凹陷"的老式扫雷立体感，你需要给每个按钮自绘，这会牵扯到BS_OWNERDRAW和DrawItem，代码量反而不比自绘视图少。第二，按钮数量一多，窗口句柄资源占用和布局管理会成为负担，虽然 9x9 不算大，但到了高级模式 16x30 的时候，体验已经能感觉到卡顿。第三，按钮没法很优雅地实现"翻开一片"的动画或透明效果，想做得像素一点很困难。
所以我最终建议把 CButton 方案定位成"快速验证思路的原型"，如果你一开始不确定自己的逻辑能不能跑通，可以先拿 CButton 最快速度做出一个能玩的版本；但如果你想做一个像样的、可发布的扫雷程序，就跳到下一个方案。
3.2 我的选择：视图自绘与命中检测
我选择的做法是基于 CView 的子类，在 OnDraw 里用 GDI 绘制全部网格。每块格子画什么由 dispMap 和 mineMap 两个数组共同决定。坐标换算很简单：先在 OnSize 里把视图的客户区尺寸存下来，然后根据行列数计算格子边长，在 OnDraw 中按(col * cellWidth, row * cellHeight)的偏移确定每个格子的绘制起点。
鼠标消息方面，在视图类里处理WM_LBUTTONDOWN和WM_RBUTTONDOWN，通过GetPosition()拿到点击点，再除以格子边长就能得到对应的行列号。这样你完全不需要动态创建任何子窗口，所有东西都是绘制的结果，逻辑非常集中。
void CMineSweeperView::OnLButtonDown(UINT nFlags, CPoint point) { int col = point.x / m_cellSize; int row = point.y / m_cellSize; if (col < 0 || col >= COLS || row < 0 || row >= ROWS) return; if (m_gameState == STATE_READY) { InitMineMap(row, col); m_gameState = STATE_PLAYING; } OpenCell(row, col); CheckWinLose(); Invalidate(); }这种做法的好处是，后续所有视觉升级——比如加上经典版扫雷的立体边框、给数字格配颜色、给插旗格画旗子，都只需要改 OnDraw 里的绘制代码，游戏逻辑可以完全不动。
3.3 绘制细节：立体边框、数字颜色与字体
经典扫雷最让人印象深刻的视觉语言，是那种略微立体的方块：未翻开时左上角亮、右下角暗，像凸起的按钮；翻开后变平。实现它不需要加载任何外部图片，GDI 画两条线就够了。
以一个格子为例，未翻开时，用白色在左上绘一条 2 像素的亮线，用深灰色在右下绘一条 2 像素的暗线，中间填浅灰色（RGB(192,192,192)），就能呈现出凸起效果。翻开后，去掉亮线和暗线，全部填成更浅一点的灰色，再画上数字。
数字颜色在经典版里有固定搭配：1 是蓝色、2 是绿色、3 是红色、4 是深蓝、5 是深红，等等。这个细节看上去小，但很吃用户的"怀旧感"，照着做就完了。字体方面，用系统默认字体就能看，如果你想更还原经典，可以用CreateFont创建一个点阵风格字体，但我实际测试下来，很多人反而更喜欢现代的等宽字体，比如 Consolas，辨识度更高。
图形接口用CDC的Rectangle、FillSolidRect或者SetPixel都行，我习惯在系统内存 DC 上把整个游戏区画好，再一次性贴到屏幕，这部分放到后面双缓冲小节详细讲。
4. 翻开、标雷与连锁扩散：游戏交互的核心逻辑实现
4.1 打开空格的"洪水填充"算法
扫雷最核心的交互体验在于：当你点开一个周围没有雷的格子时，程序会自动继续翻开周围一大片空格，直到碰到数字格为止。这个行为是一个标准的广度优先或深度优先搜索。
我的 OpenCell 函数会先递归或循环处理，为了避免递归栈溢出风险（高级模式 480 个格子问题不大，但递归习惯不好），可以用栈模拟递归：
void CMineSweeperView::OpenCell(int row, int col) { if (row < 0 || row >= ROWS || col < 0 || col >= COLS) return; if (dispMap[row][col] != 0) return; std::stack<std::pair<int,int>> stk; stk.push({row, col}); while (!stk.empty()) { auto [r, c] = stk.top(); stk.pop(); if (dispMap[r][c] != 0) continue; dispMap[r][c] = 1; if (mineMap[r][c] == 0) { for (int dr = -1; dr <= 1; dr++) for (int dc = -1; dc <= 1; dc++) if (r+dr >= 0 && r+dr < ROWS && c+dc >= 0 && c+dc < COLS) if (dispMap[r+dr][c+dc] == 0) stk.push({r+dr, c+dc}); } } }这里有两个关键细节。第一，入栈前先检查dispMap是否已翻开，否则会造成重复处理和死循环，我上面仍在循环开头加了检查作为二次保险。第二，只对mineMap[r][c] == 0的格子扩展邻居，数字格是边界，不会继续往外蔓延，符合经典扫雷的规则。
4.2 右键插旗与数字联动
右键的处理比左键简单：如果格子未翻开，循环切换状态——空开无标记 -> 插旗 -> 问号（可选）-> 取消标记。关键是插旗之后顶部的雷数计数器要实时更新，这是因为扫雷界面左上角/右上角那个数字显示的是"剩余雷数"，它的定义是"总雷数 - 已插旗数"。
还有一个很实用的细节：当数字格周围旗子数量等于它的数字时，同时左键点击数字格可以直接翻开周围剩余未翻开且未标记的格子。这个功能原本是经典扫雷提升效率的关键操作，很多人以为只有双键同时按下才触发，其实在 MFC 里就是检测左键点击的同时，判断这个格子周围的旗子数是否等于当前格子的数字。如果等于，就对周围所有既没翻开也没插旗的格子调用 OpenCell，如果其中有雷，照样判负。
void CMineSweeperView::QuickOpenIfFlagged(int row, int col) { if (mineMap[row][col] <= 0) return; int flags = CountAdjacentFlags(row, col); if (flags != mineMap[row][col]) return; for (int dr = -1; dr <= 1; dr++) for (int dc = -1; dc <= 1; dc++) { int nr = row + dr, nc = col + dc; if (nr >= 0 && nr < ROWS && nc >= 0 && nc < COLS) if (dispMap[nr][nc] == 0 && mineMap[nr][nc] != -1) OpenCell(nr, nc); } }判断mineMap[nr][nc] != -1是为了快速翻开数字区域时防止把周围雷翻开（如果你希望误点雷直接判负，可以去掉这个判断，玩家操作感受会不同）。
4.3 游戏状态的切换与外部反馈
游戏状态我用一个枚举变量维护：
enum GameState { STATE_READY, // 等待首点 STATE_PLAYING, // 进行中 STATE_WIN, // 胜利 STATE_LOSE // 失败 };每次点击之后，先更新地图状态，然后立刻判断胜负。判胜的方法是：统计未翻开的格子数，如果恰好等于总雷数，说明所有非雷格都已经被翻开，玩家获胜。注意这里不要去看"是否插了正确的旗"来判定，因为扫雷的最终胜利条件是翻开所有非雷格，插错旗但所有剩余格子都是雷也会自动判胜。
胜负判定后的落点设计上，我会在状态切换之后弹出一个MessageBox询问是否再来一局。对训练手感的人而言可能有点烦，所以我把"是否询问"做成一个菜单选项或者参数，我是直接弹框的，简单直接。
界面上除了雷区和两个数字显示，我还在菜单里放了一个"重新开始"项，快捷键 F2。这个习惯是从后来玩各种在线扫雷留下来的，没有快捷键的重开版本怎么用怎么别扭。
5. 编译运行中那些绕不开的坑：字符集、闪烁与资源管理
5.1 字符集问题：为什么你写的字符串突然报错或乱码
这是我把工程发给别人编译时遇到的第一类问题。如果你在 VS 里新建 MFC 工程，默认选中"使用 Unicode 字符集"，那么所有接收字符串的接口都变成了宽字符版本，这时你直接写SetWindowText("扫雷")会编译错误，因为窄字符串不能隐式转成宽字符串。
三种解决方案：
- 在字符串字面量前加
_T()宏，例如_T("扫雷")，工程切回多字节字符集时也能编译； - 把工程的字符集改成"使用多字节字符集"，做练习没问题，但落后时代；
- 使用
CString类型传参，它内部能帮你转换，配合_T()依然是最省心的。
我自己的建议是坚持 Unicode 字符集，在涉及中文字符串的地方用_T宏包一层，代码既现代又保险。还有一个隐藏坑是资源文件里对话框的标题，如果.rc文件里写中文，保存编码必须是 UTF-16 LE（VS 默认就是这个），否则中文会变成乱码。
5.2 画面闪烁：双缓冲的正确用法
扫雷在连续翻开大片空格时，如果不做双缓冲，画面会肉眼可见地闪烁，尤其高级模式，每次重绘几十个格子时闪烁感特别明显。闪烁的根源是窗口在重新绘制前先擦除了背景，OnEraseBkgnd 返回时应尽量拦截掉背景擦除，然后从头到尾把整帧画进内存 DC，最后一次性 BitBlt 到窗口。
标准姿势是这样：
void CMineSweeperView::OnDraw(CDC* pDC) { CRect rcClient; GetClientRect(&rcClient); CDC memDC; memDC.CreateCompatibleDC(pDC); CBitmap bmp; bmp.CreateCompatibleBitmap(pDC, rcClient.Width(), rcClient.Height()); CBitmap* pOld = memDC.SelectObject(&bmp); // 画背景 memDC.FillSolidRect(rcClient, RGB(192, 192, 192)); // 画所有格子 DrawMineMap(&memDC); // 一次性贴到屏幕 pDC->BitBlt(0, 0, rcClient.Width(), rcClient.Height(), &memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOld); }对应的头文件或消息映射里重写 OnEraseBkgnd，让它直接返回TRUE，避免窗口先擦一遍底：
BOOL CMineSweeperView::OnEraseBkgnd(CDC* /*pDC*/) { return TRUE; }改完之后，那种"扫雷翻开瞬间屏幕乱闪"的问题就彻底消失了。这也是我在实际项目里用到双缓冲最典型的场景，做进度条、画图工具都适用。
5.3 窗口尺寸变化时的坐标重算
如果你把框架窗口拖拽变大，视图客户区尺寸会改变，格子大小就需要重新计算。我第一次写的时候，格子边长是写死的 40 像素，窗口一拉就露馅了，右侧和下边直接空白，还很难看。
正确做法是在OnSize里记录当前客户区的高度和宽度，然后在绘制时计算cellWidth = clientWidth / COLS和cellHeight = clientHeight / ROWS。为了保持经典扫雷的方正感，格子最好是正方形，可以取cellSize = min(cellWidth, cellHeight)，然后额外把整个游戏区居中对齐。
窗口尺寸改变时别忘了Invalidate()主动触发重绘，否则缩小时会留下残影。
5.4 随机数的可复现性与多局游戏的重置
另一类问题出现在你连续开多局游戏时。如果只在第一次点击前调用一次初始化函数，就可能导致第二局开始时地图没重置，或者上一局的雷位残留在 mineMap 里。我用一个统一的ResetGame()函数，把mineMap、dispMap、gameState、计时器全部重置，首次点击时才真正布雷。
如果你希望某种"排雷研究"模式下可以复现同一布局，可以暂时用固定种子初始化引擎，这正好是我之前提到用mt19937的一个好处：重走同一局很轻松。
6. 除了跑通之外：几个我认为值得保留的小设计和后续扩展
这里记录几个我迭代下来觉得很重要的产品细节，不算知识点，但直接影响游戏的完成度。
第一，左上角和右上角的两个数字显示，应该做成七段数码管的样式，而不是简单的TextOut。用 GDI 去模拟七段数码管只需要画固定数量的矩形线段，网上有很多现成方案，但如果你嫌麻烦，至少保证这几个数字是等宽字体，并且背景是黑色。这个细节是扫雷"内味"的关键。
第二，计时器用SetTimer(1, 1000, NULL)，在OnTimer里更新秒数，并且只在STATE_PLAYING状态计数。胜利或失败时要用KillTimer把它停掉，否则后台会一直走数。
第三，右键插旗后，格子的绘制要把旗子作为一个小图形单独画：一根旗杆加一个红色三角形或者用 GDI 画一个小旗帜。不要用文字"F"代替，否则整个界面会变得很奇怪。
第四，关于"踩雷是否动画展示所有雷的位置"，我觉得值得做。游戏失败后，把所有雷的位置用红色背景显示出来，这样用户能知道问题出在哪，对操作手感的反馈特别重要。实现上只需要一次 Invalidate，在 OnDraw 里根据 gameState 判断渲染模式。
再往后，难度选择、自定义雷区尺寸、记录最佳成绩、加上音效，这些都是自然扩展。我实际动手时，前三个都很快就实现了，音效因为要处理文件资源而稍微繁琐一点，但也值得尝试。做完这些，你就可以说这个扫雷项目从功能到体验都比较完整了。
我在整个开发过程中最大的体会是：不要在逻辑还没跑通时就去抠视觉效果。先把"能点、能翻、能判输赢"做出来，再回头慢慢美化，效率最高，也不会因为频繁重构图导致心态崩。如果你第一次接触 MFC，整个工程代码量大约在一千行左右，分两三个晚上写完是完全现实的。遇到编译错误时，先看是不是字符集、编码或头文件包含的问题，这些占 MFC 新手报错的 70% 以上。真到了这种程度，你的 MFC 基本功就彻底打牢了。
本文还有配套的精品资源，点击获取
