简介基于MFC开发的扫雷游戏完整工程属于可直接运行与二次学习的完整源码包适合Windows C初学者和希望深入理解MFC界面编程的开发者。项目复刻了经典扫雷的雷区随机生成、左右键标记、计时与胜负判断等核心玩法源码中包含自定义对话框类与按钮类通过消息映射处理用户交互可帮助学习GUI布局、事件响应与游戏逻辑设计工程结构清晰涵盖框架、视图、文档、排序及成绩记录等模块。压缩包共71个文件约2.7MB主要由C源文件与头文件、26个位图及图标等资源文件、工程配置文件、MFC运行所需DLL和exe调试版本构成便于对照运行结果理解源码。已有475人学习浏览是课程设计、毕业设计参考或MFC项目实战练手的实用素材也可在此基础上扩展难度、音效和存档功能。1. 用 MFC 写的扫雷到底难在哪又值不值得做「用MFC开发的扫雷游戏程序(含源码)」表面上看是又一个练手小游戏但真把它拆开你会发现扫雷几乎覆盖了 MFC 桌面开发里最完整的「麻雀样本」窗口绘制、鼠标左右键消息、定时器、状态栏刷新、游戏状态机还牵扯到布雷算法和泛洪展开。难点不在逻辑本身——核心算法几百行内就能写完——而在于用 MFC 的 CView、CDC 和消息映射把这套逻辑正确地粘到 Windows 窗口上去。很多人在 VS 里新建 MFC 工程很快真正卡住的是第一次点击就炸、格子刷新闪烁、状态栏怎么都不动这些和消息循环、刷新时机有关的血泪坑。这篇笔记写给两类人刚学完 C 想用真实窗口程序练手的人以及手里有旧 MFC 工程、想照着改造一个可靠小游戏的人。2. 选型与工程骨架为什么用 MFC 写扫雷以及一个合格源码工程该长什么样2.1 扫雷是 MFC 里最典型的「全套件练手项目」桌面小游戏选项其实很多控制台五子棋、Qt 连连看、Win32 API 弹球。但扫雷在 MFC 里几乎把框架的每个关键机制都覆盖到了棋盘要响应左键和右键这是消息映射的核心应用游戏计时要挂定时器翻格子、画数字、描雷要操作设备上下文CDC雷数和秒数要推到状态栏。一套做下来你对 MFC 的消息循环和刷新模型的理解会比看十遍教程都扎实。很多人会纠结「桌面软件开发用 MFC 还是 Qt」。如果目标是快速做现代感界面、跨平台分发Qt 确实更省心但如果你面对的是工业软件、军工、医疗设备里那些存量 MFC 代码或者你只是想用最小成本把一个 C 算法跑在 Windows 窗口上MFC 的存量价值和轻量程度依然不可替代。扫雷这种小工程用 MFC 写一周能出成品用 Qt 也不见得快多少反而要在信号槽和样式表上多绕一圈。对于练手和工程课设MFC 是性价比很高的选择。对比维度MFCQt学习曲线消息映射和 DC 绘制偏底层上手痛信号槽和布局系统更现代文档全依赖体积运行库随 Windows 带发布小需要带 Qt 运行库DLL 较多适合场景存量工程维护、Windows 专用工具跨平台应用、界面复杂度高的产品扫雷这类小游戏足够且最能练到框架本质可以做但多少有点大材小用2.2 源码工程的文件划分拿到手先读哪几个文件一个标准的 MFC 单文档SDI扫雷工程文件结构是有规律的。你在 VS 里新建「MFC 应用程序」时选「单个文档」、文档/视图架构生成的基础骨架会包含几类文件应用类负责程序入口文档类负责数据序列化扫雷里可以不管它视图类负责绘制和消息响应资源文件.rc保存菜单、图标、对话框模板。但我见过很多扫雷源码工程把棋盘数组和绘制代码全怼在 CView 里整个文件上千行想改个难度都找不到地方下手。一个合格的源码工程应该把游戏核心逻辑单独抽出来做成一个不依赖 MFC 的纯 C 类比如叫 CSweepGame。它只管理三维数据棋盘格状态、显示状态、雷数、翻开数、游戏状态完全不碰 CDC 和 HWND。视图类只负责两件事把鼠标坐标换算成格子坐标调进 CSweepGame然后让窗口重绘。这样拆分的好处是第一核心逻辑可以在控制台里单测不用每次点开图形界面验证第二如果你想把这个扫雷逻辑改造成服务端算法演示或者加个 AI 自动求解器纯逻辑类直接搬走就能编译。拿到源码工程后先读 CSweepGame 的头文件再看视图类的消息映射表最后再看 OnDraw这个阅读顺序半天就能把工程吃透。2.3 格子坐标与像素坐标的换算界面层的第一道坎扫雷界面看起来是一个二维格子数组但鼠标消息给到你的只有 CPoint 像素坐标。格子坐标用行 row 和列 col 表示从 0 开始像素坐标从窗口客户区左上角开始单位是像素。两者之间差一个「棋盘绘制起点」和「格子边长」。这个换算做不对点击和绘制就会错位半个格子翻车现场极其诡异。const int CELL_SIZE 24; // 每个格子的像素边长 const int BOARD_LEFT 12; // 棋盘左边距 const int BOARD_TOP 12; // 棋盘顶边距 BOOL CSweepMinesView::GetCellFromPoint(CPoint pt, int row, int col) { if (pt.x BOARD_LEFT || pt.y BOARD_TOP) return FALSE; col (pt.x - BOARD_LEFT) / CELL_SIZE; row (pt.y - BOARD_TOP) / CELL_SIZE; if (row m_game.GetRows() || col m_game.GetCols()) return FALSE; return TRUE; }这里有两个关键参数要解释清楚。CELL_SIZE 如果取得太小比如小于 16手指或鼠标操作很容易误点相邻格子取太大大于 40又会占满屏幕30x16 的高级棋盘根本显示不下。我一般固定在 20 到 28 之间配合窗口尺寸动态调整。BOARD_LEFT 和 BOARD_TOP 的 12 像素边距是为了给棋盘留出呼吸空间也让点击不到边界处时能被上面的边界判断直接拦掉。注意 GetCellFromPoint 是先减边距再除格子边长顺序反了起点偏移会导致第一列格子死活点不中。3. 扫雷核心算法布雷、数字统计与泛洪展开3.1 布雷第一次点击必须「安全」周围一圈不能有雷扫雷程序在算法层最容易犯的错误是在初始化时就布好雷然后让玩家去点。这么做第一次点击有七分之一概率直接踩雷玩家体验极差。行业惯例是「延时布雷」第一次鼠标落下之前棋盘上只有空白第一次点击落在一个格子 (firstRow, firstCol) 之后再布雷并且这个格子和它周围 3x3 的格子全部要排除在雷点之外。void CSweepGame::InitMines(int safeRow, int safeCol) { std::mt19937 rng(std::random_device{}()); int need m_nMines; while (need 0) { int r (int)(rng() % m_nRows); int c (int)(rng() % m_nCols); if (m_board[r][c] MINE) // 已经是雷跳过 continue; if (abs(r - safeRow) 1 abs(c - safeCol) 1) continue; // 第一次点击的 3x3 区域全部留白 m_board[r][c] MINE; --need; } }这段代码里有三个参数值得展开说。m_nMines 是总雷数经典配置是初级 9x9 放 10 颗、中级 16x16 放 40 颗、高级 30x16 放 99 颗这也是 Windows 扫雷沿用多年的平衡参数。abs(r - safeRow) 1 的判断把安全区限定在 3x3 范围不是只排除点击的那一个格子因为如果只是中心点安全旁边八个格子仍可能被数字「锁死」玩家依然会觉得开局很憋屈。随机源我倾向用 std::mt19937配合随机种子设备而不是老的 rand()因为 rand() 在 VS 里的低位随机性不好可能出现雷集中在某条对角线上的情况给玩家的「玄学」体验很差。3.2 数字统计与 BFS 泛洪展开为什么不能用递归布雷完成之后要给每个非雷格子填上 0 到 8 的数字表示它周围九宫格里有多少颗雷。最直接的做法是布雷时每放一颗雷就把周围八个格子的数字加一顺手完成统计不需要二次扫描。展开是扫雷最核心的算法动作当你点开一个数字为 0 的空白格时要把与之相连的一大片空白区全部翻开。很多人第一反应是递归深度优先展开比如 while 里自己调自己代码确实短但在 30x16 的高级棋盘上一片大空场可能一次展开几百个格子递归深度在最坏情况下可能逼近棋盘尺寸。MFC 默认线程栈只有 1MB深递归很容易直接崩掉程序表现就是点开空场时窗口无响应或瞬间退出。我一般用队列做 BFS显式管理待展开队列栈上只保存一个循环。void CSweepGame::FloodOpen(int startRow, int startCol) { std::queuestd::pairint, int q; q.push({startRow, startCol}); while (!q.empty()) { auto [r, c] q.front(); q.pop(); if (r 0 || r m_nRows || c 0 || c m_nCols) continue; if (m_board[r][c] MINE) continue; if (m_show[r][c] ! COVERED) // 已翻开或已插旗不进队 continue; m_show[r][c] OPENED; m_openedCount; if (m_board[r][c] 0) { // 只有空格继续扩散有数字的格子自动停 for (int dr -1; dr 1; dr) for (int dc -1; dc 1; dc) if (dr ! 0 || dc ! 0) q.push({r dr, c dc}); } } }参数和条件要特别说清楚。m_show[r][c] ! COVERED 这个判断过滤掉了已经翻开的格子和插了旗的格子避免同一个格子反复入队造成死循环。m_board[r][c] 0 才继续扩展边界这是扫雷「点空格连片翻开」规则的精髓数字格是扩展的自然边界不用人为设深度限制。队列用 std::pair 存坐标如果有性能洁癖可以用两个 int 拼成一个 64 位整数再压队列省去 pair 的构造开销但初级棋盘几万个格子根本测不出差别可读性优先。3.3 胜利判定与剩余雷数把状态机收口胜利的条件不是「把所有雷找出来」而是「把所有非雷格子都翻开」。这个逻辑要反过来写才不容易漏判棋盘总格子数减去雷数就是安全格总数m_openedCount 每翻开一个安全格就自增当它等于安全格总数时判定胜利。bool CSweepGame::IsWin() const { return m_openedCount m_nRows * m_nCols - m_nMines; } int CSweepGame::GetMineLeft() const { int flagged 0; for (int r 0; r m_nRows; r) for (int c 0; c m_nCols; c) if (m_show[r][c] FLAGGED) flagged; return m_nMines - flagged; }这里有个实际开发中容易忽略的细节GetMineLeft 返回的「剩余雷数」在玩家乱插旗时可能变成负数。因为插旗只是玩家的标记行为不代表真的插对了位置。状态栏如果直接显示负数会显得很傻所以显示层要对小于零的值做截断或者干脆只显示 max(0, m_nMines - flagged)。这个函数我故意没有把统计值缓存成成员变量因为棋盘一共就几百个格子每次状态栏刷新时现算 900 次循环在毫秒级缓存反而要额外管理「什么时候失效」的边界问题。胜利判定要放在每次成功翻开格子之后立刻执行而不能放在 OnDraw 里判断否则会出现「明明赢了但界面没有任何反应」的诡异现象——因为绘制不会主动触发业务逻辑。4. 把算法粘到窗口上OnDraw、鼠标消息与状态栏4.1 OnDraw 双缓冲绘制画格子、画数字、画地雷视图类的 OnDraw 是 MFC 里所有绘制的总入口屏幕上每次发生变化框架都会通过 Invalidate 机制触发它重画。扫雷的绘制逻辑其实就三层先铺棋盘底色再对每个格子按显示状态画翻开或未翻开的样式最后在翻开的格子上写字或画雷。直接在每个 WM_PAINT 里调用 CDC 的画矩形和 TextOut 函数在高分屏或者程序频繁刷新时会闪屏闪到怀疑人生。闪屏的根因是系统先擦背景再画前景中间一帧露出了窗口底色。解法是双缓冲先在内存里建一个兼容位图把整帧棋盘画到内存 DC 上再一次 BitBlt 拷贝到窗口 DC。void CSweepMinesView::OnDraw(CDC* pDC) { CRect rcClient; GetClientRect(rcClient); CDC memDC; memDC.CreateCompatibleDC(pDC); CBitmap bmp; bmp.CreateCompatibleBitmap(pDC, rcClient.Width(), rcClient.Height()); CBitmap* pOldBmp memDC.SelectObject(bmp); memDC.FillSolidRect(rcClient, RGB(200, 200, 200)); for (int r 0; r m_game.GetRows(); r) { for (int c 0; c m_game.GetCols(); c) { CRect cell(BOARD_LEFT c * CELL_SIZE, BOARD_TOP r * CELL_SIZE, BOARD_LEFT (c 1) * CELL_SIZE, BOARD_TOP (r 1) * CELL_SIZE); DrawCell(memDC, r, c, cell); } } pDC-BitBlt(0, 0, rcClient.Width(), rcClient.Height(), memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOldBmp); }这段代码里 CreateCompatibleBitmap 创建的位图大小是客户区尺寸棋盘如果只有 9x9客户区更大也无所谓空余部分会被 FillSolidRect 的灰色填充。DrawCell 是自行封装的按格子状态绘制的函数未翻开画凸起效果的矩形翻开画浅色底数字用 TextOut 按颜色映射输出地雷用 LoadIcon 拖出来的 HICON 配合 DrawIcon 画。双缓冲的唯一代价是每帧多一次整图 BitBlt但对于几百个格子的棋盘完全可以忽略。注意 memDC 和 bmp 的生命周期必须在函数内结束离开作用域后 GDI 对象要释放否则反复重绘会导致 GDI 句柄泄漏程序跑一小时之后绘制开始花屏。4.2 鼠标消息左键翻开、右键插旗、左右键连点判断鼠标消息是扫雷交互的核心。左键在未翻开格子上按下并松开会翻开该格右键循环切换 插旗 → 问号 → 取消标记左右键同时在数字格上按下松开时会翻开周围八格快速翻面前提是周围旗子数刚好等于该格数字。MFC 里左右键同时按的检测要小心因为 Windows 默认不区分左右键的特殊组合状态必须自己在成员变量里记录左键是否处于按下状态。void CSweepMinesView::OnLButtonDown(UINT nFlags, CPoint point) { int row, col; if (!GetCellFromPoint(point, row, col)) return; if (m_game.IsGameOver()) return; if (!m_game.IsStarted()) { m_game.InitMines(row, col); // 第一次点击延时布雷 m_game.Start(); SetTimer(TIMER_ID, 1000, nullptr); } m_leftDown TRUE; m_leftRow row; m_leftCol col; m_game.LeftPress(row, col); } void CSweepMinesView::OnLButtonUp(UINT nFlags, CPoint point) { m_leftDown FALSE; if (m_game.IsChording(m_leftRow, m_leftCol, GetKeyState(VK_RBUTTON) 0)) { m_game.ChordOpen(m_leftRow, m_leftCol); } else { m_game.Open(m_leftRow, m_leftCol); } Invalidate(TRUE); }OnLButtonUp 里的判断逻辑是扫雷手感的关键。m_leftDown 成员变量用来记录左键按下状态因为 OnLButtonUp 触发时 nFlags 已经不包含左键状态了如果不记录右键按下时再松开左键程序会误判为「单纯右键事件」。GetKeyState(VK_RBUTTON) 判断右键是否处于按下状态左右键都在按下时松开左键就执行连点翻开。m_game.Open 里要区分三种情况点到雷直接游戏结束并翻开所有雷点到数字只翻这一格点到空格调用 FloodOpen 整片展开。插旗逻辑放在 OnRButtonDown 里循环切换三种显示状态后 Invalidate(TRUE) 只重绘棋盘区域不用整窗刷新。4.3 状态栏显示用时和剩余雷数MFC 状态栏怎么显示才能一次成功扫雷界面上雷数和秒数一般显示在状态栏右侧而状态栏在 MFC 里是很多人看了教程还是写不出来的「黑匣子」。原因多半是指示器Indicator数组和资源 ID 的对应关系搞错。状态栏要显示一段动态文本核心步骤是三步在资源文件里定义一个 ID 常量把它加进视图类的 indicators 数组再用 SetPaneText 往对应的索引位置写字符串。static UINT indicators[] { ID_SEPARATOR, // 0 号窗格默认提示区 ID_INDICATOR_TIME, // 1 号窗格显示已用时间 ID_INDICATOR_MINE // 2 号窗格显示剩余雷数 }; void CSweepMinesView::UpdateStatusBar() { CString str; str.Format(_T(时间 %d 秒), m_seconds); m_wndStatusBar.SetPaneText(1, str); str.Format(_T(剩余雷数 %d), max(0, m_game.GetMineLeft())); m_wndStatusBar.SetPaneText(2, str); }这里的坑集中在 SetPaneText 的下标上。indicators 数组的第一个元素 ID_SEPARATOR 是标准的「提示信息窗格」它占 0 号位如果你把 ID_INDICATOR_TIME 放在数组第一个位置状态栏第一格就会缩成一小条文本要么显示不全要么直接消失。另一个常见问题是只在 SetTimer 的 WM_TIMER 处理里刷新状态栏导致玩家不点棋盘时秒数不动——正确做法是让 UpdateStatusBar 成为统一的刷新出口定时器、插旗、翻开格子都调它。状态栏窗格的宽度默认很小需要在 CMainFrame::OnCreate 里调 SetPaneInfo 把 1 号窗格的宽度拉大到 90 像素否则「时间 999 秒」这类长文本会被截断。5. 扫雷 MFC 程序最常踩的 5 个坑现象、原因、解决办法5.1 坑一第一次点击必然炸开雷或被判定为踩雷现象玩家第一次点格子还没看到数字棋盘直接翻开一堆雷游戏结束。或者是第一次点击那一格不炸但它周围一圈必定有雷开局必死。原因布雷发生在初始化阶段而不是第一次点击之后。安全区只排除了点击的那一格没有排除周围 3x3。这种实现等于没做延时布雷玩家没有任何操作空間。解决把 InitMines 移到第一次 OnLButtonDown 里调用传入 (row, col)安全判断用 abs(r - safeRow) 1 abs(c - safeCol) 1把周围 8 格全部排除。之后再启动定时器开始计时计时起点也要从这时算不能从窗口创建时算。5.2 坑二翻开大空白区时程序卡死或直接崩溃现象点到一个空格周围连片翻开棋盘大范围变白但紧接着窗口无响应几秒后提示程序已停止工作。用调试模式跑断点会停在一个很深很深的位置。原因泛洪展开用了递归且递归函数在每次展开时又把 8 个方向全部递归进去。高级棋盘 30x16 的空白连片可能一次性展开 200 格以上递归深度会被叠到几百层MFC 默认线程栈扛不住直接 stack overflow。更隐蔽的是递归实现如果没做「已翻开判断」两个相邻空格会互相递归到天荒地老。解决改用队列 BFS。每次从队列里取出一个坐标先做四道过滤——越界、踩雷、已翻开、插旗全部通过后才执行翻开动作。空格才把邻居入队数字格自动终止扩散。这个改法还能顺带解决空格带数字边界的展开顺序问题数字格会在空格之后逐个被翻开效果和递归版一致但绝不会爆栈。5.3 坑三每秒刷新秒数时整个棋盘疯狂闪烁现象把定时器设成 1000 毫秒刷新状态栏但结果发现不光是状态栏在动整个棋盘每秒钟闪一次拖拽窗口时闪烁更严重。原因定时器处理函数里直接调用了 Invalidate(FALSE)触发整窗重绘。OnDraw 里又没用双缓冲每个格子的矩形绘制之间系统反复擦背景、画格子、擦背景、画格子视觉上就是高频闪烁。状态栏变化根本不需要重画棋盘这是典型的「刷新范围过大」问题。解决两层处理。第一状态栏刷新只调 SetPaneText绝不调用 Invalidate棋盘内容变化时才用 InvalidateRect 只圈出变化的格子区域比如翻开一个格子就只刷新那个格子的矩形。第二把 OnDraw 改成双缓冲绘制先把整个棋盘画进内存位图再整体 BitBlt彻底消除擦除和绘制之间的空窗期。改了这两处之后秒数走到 999 也不会闪。5.4 坑四状态栏文本显示不出来或者显示位置和大窗格挤在一起现象程序跑起来了状态栏也有但 SetPaneText 写进去的「秒数」「雷数」怎么都不显示偶尔显示了却和左侧的提示文字挤在一块。原因indicators 数组里的 ID 顺序和资源文件里 ID 的定义顺序不一致SetPaneText 下标对不上位另一个常见原因是状态栏窗格宽度没有被 SetPaneInfo 拉开文本画在了不可见的区域里。ID_SEPARATOR 放在数组第一个元素但资源文件里 ID_INDICATOR_TIME 排在它前面消息映射就把索引搞乱了。解决先确认 indicators 数组里第一个元素必须是 ID_SEPARATOR它占 0 号动态文本从 1 号开始。然后在 CMainFrame::OnCreate 里对每个要显示动态文本的窗格调 SetPaneInfo(1, ID_INDICATOR_TIME, SBPS_NORMAL, 90)第四参数是宽度像素值。最后用 Spy 或临时写死字符串验证 SetPaneText 的第一个参数索引排错时先把文本写死成「测试」确认显示链路通再换成动态变量。这个排错顺序能省下大量排查时间。5.5 坑五左右键同时点的「快速翻开」经常误触或者根本触发不了现象按住右键后再点左键左键那一下直接触发了单人翻格快速翻面没有生效或者反过来左键按着去点右键反而炸开了一片雷。原因Windows 的鼠标消息里OnLButtonDown 和 OnRButtonDown 是两个独立事件系统不给你「左右键组合」的现成通知。如果不在按下时记录状态松开时就去查另一端是否还按着大概率已经查不到。比如你先按下左键系统立刻触发了 OnLButtonDown 里的 Open 逻辑还没等你按右键格子已经被翻开了。解决把「翻开」动作从 OnLButtonDown 挪到 OnLButtonUp 里执行。按下时只记录坐标和左键状态松开时才判断如果此时右键也处于按下状态执行连点翻开周围八格否则执行普通翻开。同样右键按下时也不要立刻插旗等 OnRButtonUp 再执行。这样左右键无论按下顺序如何组合逻辑都只发生在松开的那一颗。注意连点翻开的判定条件还要带上 m_game.IsChording周围旗子数必须等于该格数字否则就算左右键同时按也无法强制翻开这是扫雷的规则边界。6. 装一个自动验证脚本2000 局帮你找出算法死角扫雷逻辑写完后最怕的是「手动玩了几盘看起来正常但雷总数不对、数字越界、胜利判定不触发」这类隐蔽问题。我自己的习惯是把 CSweepGame 做成纯 C 类之后立刻写一个不依赖 MFC 的控制台验证程序批量模拟点击把算法死角全部炸出来。这个验证脚本成本很低但对「拿到源码后想改造成课设或加功能」来说是判断这套代码值不值得继续投入的关键。验证程序要模拟三类操作随机点击未翻开的格子、对已翻开的数字格做左右键连点、在雷密集区域随机插旗。核心校验点有三个布雷数量必须严格等于设定值所有翻开的格子数字必须和周围实际雷数一致2000 局里不能出现一次崩溃或死循环。下面是一段最小验证框架int main() { std::mt19937 rng(42); int winCount 0; const int TRIALS 2000; for (int t 0; t TRIALS; t) { CSweepGame game(16, 16, 40); game.InitMines(-1, -1); // 不设安全区跑纯算法正确性 int guard 0; while (!game.IsGameOver() guard 10000) { int r (int)(rng() % game.GetRows()); int c (int)(rng() % game.GetCols()); game.Open(r, c); guard; if (guard 5000) break; // 防止随机策略把局面拖死 } if (game.IsWin()) winCount; // 校验雷数 int mineSum 0; for (int r 0; r game.GetRows(); r) for (int c 0; c game.GetCols(); c) if (game.GetCell(r, c) MINE) mineSum; assert(mineSum 40); } printf(胜利局数: %d / %d\n, winCount, TRIALS); return 0; }这段脚本里 InitMines(-1, -1) 故意传非法坐标让布雷逻辑跳过安全区过滤专门测试算法在极端情况下的稳定性。guard 变量是防死循环的保险丝因为纯随机策略可能永远点不完安全格超过 5000 步就主动切下一局。assert 雷数校验能在 Debug 模式下第一时间暴露布雷漏雷或重复布雷的问题。跑完之后胜率高低不重要——随机点击策略本来就不聪明——重要的是它不崩溃、不挂起、雷数恒定、数字无越界。这四点过了你才可以放心把逻辑接回界面层继续做交互优化。我的血泪经验是MFC 界面代码的问题往往一眼能看出来而算法层的问题会伪装成「偶尔闪退」「某局判输错误」这种玄学 bug。把核心逻辑拆出去做无头测试是给自己的后悔药。扫雷这种工程量级的项目验证脚本半小时就能写完但它能在你发布源码之前把最掉链子的角落全部兜住。希望这套从选型、骨架、算法到排错的完整链路能帮你把「用 MFC 开发的扫雷游戏程序」真正做成一个拿得出手、敢给别人看的工程。本文还有配套的精品资源点击获取