簡(jiǎn)介基于MFC開發(fā)的掃雷游戲完整工程屬于可直接運(yùn)行與二次學(xué)習(xí)的完整源碼包適合Windows C初學(xué)者和希望深入理解MFC界面編程的開發(fā)者。項(xiàng)目復(fù)刻了經(jīng)典掃雷的雷區(qū)隨機(jī)生成、左右鍵標(biāo)記、計(jì)時(shí)與勝負(fù)判斷等核心玩法源碼中包含自定義對(duì)話框類與按鈕類通過消息映射處理用戶交互可幫助學(xué)習(xí)GUI布局、事件響應(yīng)與游戲邏輯設(shè)計(jì)工程結(jié)構(gòu)清晰涵蓋框架、視圖、文檔、排序及成績(jī)記錄等模塊。壓縮包共71個(gè)文件約2.7MB主要由C源文件與頭文件、26個(gè)位圖及圖標(biāo)等資源文件、工程配置文件、MFC運(yùn)行所需DLL和exe調(diào)試版本構(gòu)成便于對(duì)照運(yùn)行結(jié)果理解源碼。已有475人學(xué)習(xí)瀏覽是課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)參考或MFC項(xiàng)目實(shí)戰(zhàn)練手的實(shí)用素材也可在此基礎(chǔ)上擴(kuò)展難度、音效和存檔功能。1. 用 MFC 寫的掃雷到底難在哪又值不值得做「用MFC開發(fā)的掃雷游戲程序(含源碼)」表面上看是又一個(gè)練手小游戲但真把它拆開你會(huì)發(fā)現(xiàn)掃雷幾乎覆蓋了 MFC 桌面開發(fā)里最完整的「麻雀樣本」窗口繪制、鼠標(biāo)左右鍵消息、定時(shí)器、狀態(tài)欄刷新、游戲狀態(tài)機(jī)還牽扯到布雷算法和泛洪展開。難點(diǎn)不在邏輯本身——核心算法幾百行內(nèi)就能寫完——而在于用 MFC 的 CView、CDC 和消息映射把這套邏輯正確地粘到 Windows 窗口上去。很多人在 VS 里新建 MFC 工程很快真正卡住的是第一次點(diǎn)擊就炸、格子刷新閃爍、狀態(tài)欄怎么都不動(dòng)這些和消息循環(huán)、刷新時(shí)機(jī)有關(guān)的血淚坑。這篇筆記寫給兩類人剛學(xué)完 C 想用真實(shí)窗口程序練手的人以及手里有舊 MFC 工程、想照著改造一個(gè)可靠小游戲的人。2. 選型與工程骨架為什么用 MFC 寫掃雷以及一個(gè)合格源碼工程該長(zhǎng)什么樣2.1 掃雷是 MFC 里最典型的「全套件練手項(xiàng)目」桌面小游戲選項(xiàng)其實(shí)很多控制臺(tái)五子棋、Qt 連連看、Win32 API 彈球。但掃雷在 MFC 里幾乎把框架的每個(gè)關(guān)鍵機(jī)制都覆蓋到了棋盤要響應(yīng)左鍵和右鍵這是消息映射的核心應(yīng)用游戲計(jì)時(shí)要掛定時(shí)器翻格子、畫數(shù)字、描雷要操作設(shè)備上下文CDC雷數(shù)和秒數(shù)要推到狀態(tài)欄。一套做下來你對(duì) MFC 的消息循環(huán)和刷新模型的理解會(huì)比看十遍教程都扎實(shí)。很多人會(huì)糾結(jié)「桌面軟件開發(fā)用 MFC 還是 Qt」。如果目標(biāo)是快速做現(xiàn)代感界面、跨平臺(tái)分發(fā)Qt 確實(shí)更省心但如果你面對(duì)的是工業(yè)軟件、軍工、醫(yī)療設(shè)備里那些存量 MFC 代碼或者你只是想用最小成本把一個(gè) C 算法跑在 Windows 窗口上MFC 的存量?jī)r(jià)值和輕量程度依然不可替代。掃雷這種小工程用 MFC 寫一周能出成品用 Qt 也不見得快多少反而要在信號(hào)槽和樣式表上多繞一圈。對(duì)于練手和工程課設(shè)MFC 是性價(jià)比很高的選擇。對(duì)比維度MFCQt學(xué)習(xí)曲線消息映射和 DC 繪制偏底層上手痛信號(hào)槽和布局系統(tǒng)更現(xiàn)代文檔全依賴體積運(yùn)行庫隨 Windows 帶發(fā)布小需要帶 Qt 運(yùn)行庫DLL 較多適合場(chǎng)景存量工程維護(hù)、Windows 專用工具跨平臺(tái)應(yīng)用、界面復(fù)雜度高的產(chǎn)品掃雷這類小游戲足夠且最能練到框架本質(zhì)可以做但多少有點(diǎn)大材小用2.2 源碼工程的文件劃分拿到手先讀哪幾個(gè)文件一個(gè)標(biāo)準(zhǔn)的 MFC 單文檔SDI掃雷工程文件結(jié)構(gòu)是有規(guī)律的。你在 VS 里新建「MFC 應(yīng)用程序」時(shí)選「單個(gè)文檔」、文檔/視圖架構(gòu)生成的基礎(chǔ)骨架會(huì)包含幾類文件應(yīng)用類負(fù)責(zé)程序入口文檔類負(fù)責(zé)數(shù)據(jù)序列化掃雷里可以不管它視圖類負(fù)責(zé)繪制和消息響應(yīng)資源文件.rc保存菜單、圖標(biāo)、對(duì)話框模板。但我見過很多掃雷源碼工程把棋盤數(shù)組和繪制代碼全懟在 CView 里整個(gè)文件上千行想改個(gè)難度都找不到地方下手。一個(gè)合格的源碼工程應(yīng)該把游戲核心邏輯單獨(dú)抽出來做成一個(gè)不依賴 MFC 的純 C 類比如叫 CSweepGame。它只管理三維數(shù)據(jù)棋盤格狀態(tài)、顯示狀態(tài)、雷數(shù)、翻開數(shù)、游戲狀態(tài)完全不碰 CDC 和 HWND。視圖類只負(fù)責(zé)兩件事把鼠標(biāo)坐標(biāo)換算成格子坐標(biāo)調(diào)進(jìn) CSweepGame然后讓窗口重繪。這樣拆分的好處是第一核心邏輯可以在控制臺(tái)里單測(cè)不用每次點(diǎn)開圖形界面驗(yàn)證第二如果你想把這個(gè)掃雷邏輯改造成服務(wù)端算法演示或者加個(gè) AI 自動(dòng)求解器純邏輯類直接搬走就能編譯。拿到源碼工程后先讀 CSweepGame 的頭文件再看視圖類的消息映射表最后再看 OnDraw這個(gè)閱讀順序半天就能把工程吃透。2.3 格子坐標(biāo)與像素坐標(biāo)的換算界面層的第一道坎掃雷界面看起來是一個(gè)二維格子數(shù)組但鼠標(biāo)消息給到你的只有 CPoint 像素坐標(biāo)。格子坐標(biāo)用行 row 和列 col 表示從 0 開始像素坐標(biāo)從窗口客戶區(qū)左上角開始單位是像素。兩者之間差一個(gè)「棋盤繪制起點(diǎn)」和「格子邊長(zhǎng)」。這個(gè)換算做不對(duì)點(diǎn)擊和繪制就會(huì)錯(cuò)位半個(gè)格子翻車現(xiàn)場(chǎng)極其詭異。const int CELL_SIZE 24; // 每個(gè)格子的像素邊長(zhǎng) 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; }這里有兩個(gè)關(guān)鍵參數(shù)要解釋清楚。CELL_SIZE 如果取得太小比如小于 16手指或鼠標(biāo)操作很容易誤點(diǎn)相鄰格子取太大大于 40又會(huì)占滿屏幕30x16 的高級(jí)棋盤根本顯示不下。我一般固定在 20 到 28 之間配合窗口尺寸動(dòng)態(tài)調(diào)整。BOARD_LEFT 和 BOARD_TOP 的 12 像素邊距是為了給棋盤留出呼吸空間也讓點(diǎn)擊不到邊界處時(shí)能被上面的邊界判斷直接攔掉。注意 GetCellFromPoint 是先減邊距再除格子邊長(zhǎng)順序反了起點(diǎn)偏移會(huì)導(dǎo)致第一列格子死活點(diǎn)不中。3. 掃雷核心算法布雷、數(shù)字統(tǒng)計(jì)與泛洪展開3.1 布雷第一次點(diǎn)擊必須「安全」周圍一圈不能有雷掃雷程序在算法層最容易犯的錯(cuò)誤是在初始化時(shí)就布好雷然后讓玩家去點(diǎn)。這么做第一次點(diǎn)擊有七分之一概率直接踩雷玩家體驗(yàn)極差。行業(yè)慣例是「延時(shí)布雷」第一次鼠標(biāo)落下之前棋盤上只有空白第一次點(diǎn)擊落在一個(gè)格子 (firstRow, firstCol) 之后再布雷并且這個(gè)格子和它周圍 3x3 的格子全部要排除在雷點(diǎn)之外。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) // 已經(jīng)是雷跳過 continue; if (abs(r - safeRow) 1 abs(c - safeCol) 1) continue; // 第一次點(diǎn)擊的 3x3 區(qū)域全部留白 m_board[r][c] MINE; --need; } }這段代碼里有三個(gè)參數(shù)值得展開說。m_nMines 是總雷數(shù)經(jīng)典配置是初級(jí) 9x9 放 10 顆、中級(jí) 16x16 放 40 顆、高級(jí) 30x16 放 99 顆這也是 Windows 掃雷沿用多年的平衡參數(shù)。abs(r - safeRow) 1 的判斷把安全區(qū)限定在 3x3 范圍不是只排除點(diǎn)擊的那一個(gè)格子因?yàn)槿绻皇侵行狞c(diǎn)安全旁邊八個(gè)格子仍可能被數(shù)字「鎖死」玩家依然會(huì)覺得開局很憋屈。隨機(jī)源我傾向用 std::mt19937配合隨機(jī)種子設(shè)備而不是老的 rand()因?yàn)?rand() 在 VS 里的低位隨機(jī)性不好可能出現(xiàn)雷集中在某條對(duì)角線上的情況給玩家的「玄學(xué)」體驗(yàn)很差。3.2 數(shù)字統(tǒng)計(jì)與 BFS 泛洪展開為什么不能用遞歸布雷完成之后要給每個(gè)非雷格子填上 0 到 8 的數(shù)字表示它周圍九宮格里有多少顆雷。最直接的做法是布雷時(shí)每放一顆雷就把周圍八個(gè)格子的數(shù)字加一順手完成統(tǒng)計(jì)不需要二次掃描。展開是掃雷最核心的算法動(dòng)作當(dāng)你點(diǎn)開一個(gè)數(shù)字為 0 的空白格時(shí)要把與之相連的一大片空白區(qū)全部翻開。很多人第一反應(yīng)是遞歸深度優(yōu)先展開比如 while 里自己調(diào)自己代碼確實(shí)短但在 30x16 的高級(jí)棋盤上一片大空?qǐng)隹赡芤淮握归_幾百個(gè)格子遞歸深度在最壞情況下可能逼近棋盤尺寸。MFC 默認(rèn)線程棧只有 1MB深遞歸很容易直接崩掉程序表現(xiàn)就是點(diǎn)開空?qǐng)鰰r(shí)窗口無響應(yīng)或瞬間退出。我一般用隊(duì)列做 BFS顯式管理待展開隊(duì)列棧上只保存一個(gè)循環(huán)。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) // 已翻開或已插旗不進(jìn)隊(duì) continue; m_show[r][c] OPENED; m_openedCount; if (m_board[r][c] 0) { // 只有空格繼續(xù)擴(kuò)散有數(shù)字的格子自動(dòng)停 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}); } } }參數(shù)和條件要特別說清楚。m_show[r][c] ! COVERED 這個(gè)判斷過濾掉了已經(jīng)翻開的格子和插了旗的格子避免同一個(gè)格子反復(fù)入隊(duì)造成死循環(huán)。m_board[r][c] 0 才繼續(xù)擴(kuò)展邊界這是掃雷「點(diǎn)空格連片翻開」規(guī)則的精髓數(shù)字格是擴(kuò)展的自然邊界不用人為設(shè)深度限制。隊(duì)列用 std::pair 存坐標(biāo)如果有性能潔癖可以用兩個(gè) int 拼成一個(gè) 64 位整數(shù)再壓隊(duì)列省去 pair 的構(gòu)造開銷但初級(jí)棋盤幾萬個(gè)格子根本測(cè)不出差別可讀性優(yōu)先。3.3 勝利判定與剩余雷數(shù)把狀態(tài)機(jī)收口勝利的條件不是「把所有雷找出來」而是「把所有非雷格子都翻開」。這個(gè)邏輯要反過來寫才不容易漏判棋盤總格子數(shù)減去雷數(shù)就是安全格總數(shù)m_openedCount 每翻開一個(gè)安全格就自增當(dāng)它等于安全格總數(shù)時(shí)判定勝利。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; }這里有個(gè)實(shí)際開發(fā)中容易忽略的細(xì)節(jié)GetMineLeft 返回的「剩余雷數(shù)」在玩家亂插旗時(shí)可能變成負(fù)數(shù)。因?yàn)椴迤熘皇峭婕业臉?biāo)記行為不代表真的插對(duì)了位置。狀態(tài)欄如果直接顯示負(fù)數(shù)會(huì)顯得很傻所以顯示層要對(duì)小于零的值做截?cái)嗷蛘吒纱嘀伙@示 max(0, m_nMines - flagged)。這個(gè)函數(shù)我故意沒有把統(tǒng)計(jì)值緩存成成員變量因?yàn)槠灞P一共就幾百個(gè)格子每次狀態(tài)欄刷新時(shí)現(xiàn)算 900 次循環(huán)在毫秒級(jí)緩存反而要額外管理「什么時(shí)候失效」的邊界問題。勝利判定要放在每次成功翻開格子之后立刻執(zhí)行而不能放在 OnDraw 里判斷否則會(huì)出現(xiàn)「明明贏了但界面沒有任何反應(yīng)」的詭異現(xiàn)象——因?yàn)槔L制不會(huì)主動(dòng)觸發(fā)業(yè)務(wù)邏輯。4. 把算法粘到窗口上OnDraw、鼠標(biāo)消息與狀態(tài)欄4.1 OnDraw 雙緩沖繪制畫格子、畫數(shù)字、畫地雷視圖類的 OnDraw 是 MFC 里所有繪制的總?cè)肟谄聊簧厦看伟l(fā)生變化框架都會(huì)通過 Invalidate 機(jī)制觸發(fā)它重畫。掃雷的繪制邏輯其實(shí)就三層先鋪棋盤底色再對(duì)每個(gè)格子按顯示狀態(tài)畫翻開或未翻開的樣式最后在翻開的格子上寫字或畫雷。直接在每個(gè) WM_PAINT 里調(diào)用 CDC 的畫矩形和 TextOut 函數(shù)在高分屏或者程序頻繁刷新時(shí)會(huì)閃屏閃到懷疑人生。閃屏的根因是系統(tǒng)先擦背景再畫前景中間一幀露出了窗口底色。解法是雙緩沖先在內(nèi)存里建一個(gè)兼容位圖把整幀棋盤畫到內(nèi)存 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 創(chuàng)建的位圖大小是客戶區(qū)尺寸棋盤如果只有 9x9客戶區(qū)更大也無所謂空余部分會(huì)被 FillSolidRect 的灰色填充。DrawCell 是自行封裝的按格子狀態(tài)繪制的函數(shù)未翻開畫凸起效果的矩形翻開畫淺色底數(shù)字用 TextOut 按顏色映射輸出地雷用 LoadIcon 拖出來的 HICON 配合 DrawIcon 畫。雙緩沖的唯一代價(jià)是每幀多一次整圖 BitBlt但對(duì)于幾百個(gè)格子的棋盤完全可以忽略。注意 memDC 和 bmp 的生命周期必須在函數(shù)內(nèi)結(jié)束離開作用域后 GDI 對(duì)象要釋放否則反復(fù)重繪會(huì)導(dǎo)致 GDI 句柄泄漏程序跑一小時(shí)之后繪制開始花屏。4.2 鼠標(biāo)消息左鍵翻開、右鍵插旗、左右鍵連點(diǎn)判斷鼠標(biāo)消息是掃雷交互的核心。左鍵在未翻開格子上按下并松開會(huì)翻開該格右鍵循環(huán)切換 插旗 → 問號(hào) → 取消標(biāo)記左右鍵同時(shí)在數(shù)字格上按下松開時(shí)會(huì)翻開周圍八格快速翻面前提是周圍旗子數(shù)剛好等于該格數(shù)字。MFC 里左右鍵同時(shí)按的檢測(cè)要小心因?yàn)?Windows 默認(rèn)不區(qū)分左右鍵的特殊組合狀態(tài)必須自己在成員變量里記錄左鍵是否處于按下狀態(tài)。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); // 第一次點(diǎn)擊延時(shí)布雷 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 里的判斷邏輯是掃雷手感的關(guān)鍵。m_leftDown 成員變量用來記錄左鍵按下狀態(tài)因?yàn)?OnLButtonUp 觸發(fā)時(shí) nFlags 已經(jīng)不包含左鍵狀態(tài)了如果不記錄右鍵按下時(shí)再松開左鍵程序會(huì)誤判為「單純右鍵事件」。GetKeyState(VK_RBUTTON) 判斷右鍵是否處于按下狀態(tài)左右鍵都在按下時(shí)松開左鍵就執(zhí)行連點(diǎn)翻開。m_game.Open 里要區(qū)分三種情況點(diǎn)到雷直接游戲結(jié)束并翻開所有雷點(diǎn)到數(shù)字只翻這一格點(diǎn)到空格調(diào)用 FloodOpen 整片展開。插旗邏輯放在 OnRButtonDown 里循環(huán)切換三種顯示狀態(tài)后 Invalidate(TRUE) 只重繪棋盤區(qū)域不用整窗刷新。4.3 狀態(tài)欄顯示用時(shí)和剩余雷數(shù)MFC 狀態(tài)欄怎么顯示才能一次成功掃雷界面上雷數(shù)和秒數(shù)一般顯示在狀態(tài)欄右側(cè)而狀態(tài)欄在 MFC 里是很多人看了教程還是寫不出來的「黑匣子」。原因多半是指示器Indicator數(shù)組和資源 ID 的對(duì)應(yīng)關(guān)系搞錯(cuò)。狀態(tài)欄要顯示一段動(dòng)態(tài)文本核心步驟是三步在資源文件里定義一個(gè) ID 常量把它加進(jìn)視圖類的 indicators 數(shù)組再用 SetPaneText 往對(duì)應(yīng)的索引位置寫字符串。static UINT indicators[] { ID_SEPARATOR, // 0 號(hào)窗格默認(rèn)提示區(qū) ID_INDICATOR_TIME, // 1 號(hào)窗格顯示已用時(shí)間 ID_INDICATOR_MINE // 2 號(hào)窗格顯示剩余雷數(shù) }; void CSweepMinesView::UpdateStatusBar() { CString str; str.Format(_T(時(shí)間 %d 秒), m_seconds); m_wndStatusBar.SetPaneText(1, str); str.Format(_T(剩余雷數(shù) %d), max(0, m_game.GetMineLeft())); m_wndStatusBar.SetPaneText(2, str); }這里的坑集中在 SetPaneText 的下標(biāo)上。indicators 數(shù)組的第一個(gè)元素 ID_SEPARATOR 是標(biāo)準(zhǔn)的「提示信息窗格」它占 0 號(hào)位如果你把 ID_INDICATOR_TIME 放在數(shù)組第一個(gè)位置狀態(tài)欄第一格就會(huì)縮成一小條文本要么顯示不全要么直接消失。另一個(gè)常見問題是只在 SetTimer 的 WM_TIMER 處理里刷新狀態(tài)欄導(dǎo)致玩家不點(diǎn)棋盤時(shí)秒數(shù)不動(dòng)——正確做法是讓 UpdateStatusBar 成為統(tǒng)一的刷新出口定時(shí)器、插旗、翻開格子都調(diào)它。狀態(tài)欄窗格的寬度默認(rèn)很小需要在 CMainFrame::OnCreate 里調(diào) SetPaneInfo 把 1 號(hào)窗格的寬度拉大到 90 像素否則「時(shí)間 999 秒」這類長(zhǎng)文本會(huì)被截?cái)唷?. 掃雷 MFC 程序最常踩的 5 個(gè)坑現(xiàn)象、原因、解決辦法5.1 坑一第一次點(diǎn)擊必然炸開雷或被判定為踩雷現(xiàn)象玩家第一次點(diǎn)格子還沒看到數(shù)字棋盤直接翻開一堆雷游戲結(jié)束?；蛘呤堑谝淮吸c(diǎn)擊那一格不炸但它周圍一圈必定有雷開局必死。原因布雷發(fā)生在初始化階段而不是第一次點(diǎn)擊之后。安全區(qū)只排除了點(diǎn)擊的那一格沒有排除周圍 3x3。這種實(shí)現(xiàn)等于沒做延時(shí)布雷玩家沒有任何操作空間。解決把 InitMines 移到第一次 OnLButtonDown 里調(diào)用傳入 (row, col)安全判斷用 abs(r - safeRow) 1 abs(c - safeCol) 1把周圍 8 格全部排除。之后再啟動(dòng)定時(shí)器開始計(jì)時(shí)計(jì)時(shí)起點(diǎn)也要從這時(shí)算不能從窗口創(chuàng)建時(shí)算。5.2 坑二翻開大空白區(qū)時(shí)程序卡死或直接崩潰現(xiàn)象點(diǎn)到一個(gè)空格周圍連片翻開棋盤大范圍變白但緊接著窗口無響應(yīng)幾秒后提示程序已停止工作。用調(diào)試模式跑斷點(diǎn)會(huì)停在一個(gè)很深很深的位置。原因泛洪展開用了遞歸且遞歸函數(shù)在每次展開時(shí)又把 8 個(gè)方向全部遞歸進(jìn)去。高級(jí)棋盤 30x16 的空白連片可能一次性展開 200 格以上遞歸深度會(huì)被疊到幾百層MFC 默認(rèn)線程棧扛不住直接 stack overflow。更隱蔽的是遞歸實(shí)現(xiàn)如果沒做「已翻開判斷」兩個(gè)相鄰空格會(huì)互相遞歸到天荒地老。解決改用隊(duì)列 BFS。每次從隊(duì)列里取出一個(gè)坐標(biāo)先做四道過濾——越界、踩雷、已翻開、插旗全部通過后才執(zhí)行翻開動(dòng)作。空格才把鄰居入隊(duì)數(shù)字格自動(dòng)終止擴(kuò)散。這個(gè)改法還能順帶解決空格帶數(shù)字邊界的展開順序問題數(shù)字格會(huì)在空格之后逐個(gè)被翻開效果和遞歸版一致但絕不會(huì)爆棧。5.3 坑三每秒刷新秒數(shù)時(shí)整個(gè)棋盤瘋狂閃爍現(xiàn)象把定時(shí)器設(shè)成 1000 毫秒刷新狀態(tài)欄但結(jié)果發(fā)現(xiàn)不光是狀態(tài)欄在動(dòng)整個(gè)棋盤每秒鐘閃一次拖拽窗口時(shí)閃爍更嚴(yán)重。原因定時(shí)器處理函數(shù)里直接調(diào)用了 Invalidate(FALSE)觸發(fā)整窗重繪。OnDraw 里又沒用雙緩沖每個(gè)格子的矩形繪制之間系統(tǒng)反復(fù)擦背景、畫格子、擦背景、畫格子視覺上就是高頻閃爍。狀態(tài)欄變化根本不需要重畫棋盤這是典型的「刷新范圍過大」問題。解決兩層處理。第一狀態(tài)欄刷新只調(diào) SetPaneText絕不調(diào)用 Invalidate棋盤內(nèi)容變化時(shí)才用 InvalidateRect 只圈出變化的格子區(qū)域比如翻開一個(gè)格子就只刷新那個(gè)格子的矩形。第二把 OnDraw 改成雙緩沖繪制先把整個(gè)棋盤畫進(jìn)內(nèi)存位圖再整體 BitBlt徹底消除擦除和繪制之間的空窗期。改了這兩處之后秒數(shù)走到 999 也不會(huì)閃。5.4 坑四狀態(tài)欄文本顯示不出來或者顯示位置和大窗格擠在一起現(xiàn)象程序跑起來了狀態(tài)欄也有但 SetPaneText 寫進(jìn)去的「秒數(shù)」「雷數(shù)」怎么都不顯示偶爾顯示了卻和左側(cè)的提示文字?jǐn)D在一塊。原因indicators 數(shù)組里的 ID 順序和資源文件里 ID 的定義順序不一致SetPaneText 下標(biāo)對(duì)不上位另一個(gè)常見原因是狀態(tài)欄窗格寬度沒有被 SetPaneInfo 拉開文本畫在了不可見的區(qū)域里。ID_SEPARATOR 放在數(shù)組第一個(gè)元素但資源文件里 ID_INDICATOR_TIME 排在它前面消息映射就把索引搞亂了。解決先確認(rèn) indicators 數(shù)組里第一個(gè)元素必須是 ID_SEPARATOR它占 0 號(hào)動(dòng)態(tài)文本從 1 號(hào)開始。然后在 CMainFrame::OnCreate 里對(duì)每個(gè)要顯示動(dòng)態(tài)文本的窗格調(diào) SetPaneInfo(1, ID_INDICATOR_TIME, SBPS_NORMAL, 90)第四參數(shù)是寬度像素值。最后用 Spy 或臨時(shí)寫死字符串驗(yàn)證 SetPaneText 的第一個(gè)參數(shù)索引排錯(cuò)時(shí)先把文本寫死成「測(cè)試」確認(rèn)顯示鏈路通再換成動(dòng)態(tài)變量。這個(gè)排錯(cuò)順序能省下大量排查時(shí)間。5.5 坑五左右鍵同時(shí)點(diǎn)的「快速翻開」經(jīng)常誤觸或者根本觸發(fā)不了現(xiàn)象按住右鍵后再點(diǎn)左鍵左鍵那一下直接觸發(fā)了單人翻格快速翻面沒有生效或者反過來左鍵按著去點(diǎn)右鍵反而炸開了一片雷。原因Windows 的鼠標(biāo)消息里OnLButtonDown 和 OnRButtonDown 是兩個(gè)獨(dú)立事件系統(tǒng)不給你「左右鍵組合」的現(xiàn)成通知。如果不在按下時(shí)記錄狀態(tài)松開時(shí)就去查另一端是否還按著大概率已經(jīng)查不到。比如你先按下左鍵系統(tǒng)立刻觸發(fā)了 OnLButtonDown 里的 Open 邏輯還沒等你按右鍵格子已經(jīng)被翻開了。解決把「翻開」動(dòng)作從 OnLButtonDown 挪到 OnLButtonUp 里執(zhí)行。按下時(shí)只記錄坐標(biāo)和左鍵狀態(tài)松開時(shí)才判斷如果此時(shí)右鍵也處于按下狀態(tài)執(zhí)行連點(diǎn)翻開周圍八格否則執(zhí)行普通翻開。同樣右鍵按下時(shí)也不要立刻插旗等 OnRButtonUp 再執(zhí)行。這樣左右鍵無論按下順序如何組合邏輯都只發(fā)生在松開的那一顆。注意連點(diǎn)翻開的判定條件還要帶上 m_game.IsChording周圍旗子數(shù)必須等于該格數(shù)字否則就算左右鍵同時(shí)按也無法強(qiáng)制翻開這是掃雷的規(guī)則邊界。6. 裝一個(gè)自動(dòng)驗(yàn)證腳本2000 局幫你找出算法死角掃雷邏輯寫完后最怕的是「手動(dòng)玩了幾盤看起來正常但雷總數(shù)不對(duì)、數(shù)字越界、勝利判定不觸發(fā)」這類隱蔽問題。我自己的習(xí)慣是把 CSweepGame 做成純 C 類之后立刻寫一個(gè)不依賴 MFC 的控制臺(tái)驗(yàn)證程序批量模擬點(diǎn)擊把算法死角全部炸出來。這個(gè)驗(yàn)證腳本成本很低但對(duì)「拿到源碼后想改造成課設(shè)或加功能」來說是判斷這套代碼值不值得繼續(xù)投入的關(guān)鍵。驗(yàn)證程序要模擬三類操作隨機(jī)點(diǎn)擊未翻開的格子、對(duì)已翻開的數(shù)字格做左右鍵連點(diǎn)、在雷密集區(qū)域隨機(jī)插旗。核心校驗(yàn)點(diǎn)有三個(gè)布雷數(shù)量必須嚴(yán)格等于設(shè)定值所有翻開的格子數(shù)字必須和周圍實(shí)際雷數(shù)一致2000 局里不能出現(xiàn)一次崩潰或死循環(huán)。下面是一段最小驗(yàn)證框架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); // 不設(shè)安全區(qū)跑純算法正確性 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; // 防止隨機(jī)策略把局面拖死 } if (game.IsWin()) winCount; // 校驗(yàn)雷數(shù) 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(勝利局?jǐn)?shù): %d / %d\n, winCount, TRIALS); return 0; }這段腳本里 InitMines(-1, -1) 故意傳非法坐標(biāo)讓布雷邏輯跳過安全區(qū)過濾專門測(cè)試算法在極端情況下的穩(wěn)定性。guard 變量是防死循環(huán)的保險(xiǎn)絲因?yàn)榧冸S機(jī)策略可能永遠(yuǎn)點(diǎn)不完安全格超過 5000 步就主動(dòng)切下一局。assert 雷數(shù)校驗(yàn)?zāi)茉?Debug 模式下第一時(shí)間暴露布雷漏雷或重復(fù)布雷的問題。跑完之后勝率高低不重要——隨機(jī)點(diǎn)擊策略本來就不聰明——重要的是它不崩潰、不掛起、雷數(shù)恒定、數(shù)字無越界。這四點(diǎn)過了你才可以放心把邏輯接回界面層繼續(xù)做交互優(yōu)化。我的血淚經(jīng)驗(yàn)是MFC 界面代碼的問題往往一眼能看出來而算法層的問題會(huì)偽裝成「偶爾閃退」「某局判輸錯(cuò)誤」這種玄學(xué) bug。把核心邏輯拆出去做無頭測(cè)試是給自己的后悔藥。掃雷這種工程量級(jí)的項(xiàng)目驗(yàn)證腳本半小時(shí)就能寫完但它能在你發(fā)布源碼之前把最掉鏈子的角落全部兜住。希望這套從選型、骨架、算法到排錯(cuò)的完整鏈路能幫你把「用 MFC 開發(fā)的掃雷游戲程序」真正做成一個(gè)拿得出手、敢給別人看的工程。本文還有配套的精品資源點(diǎn)擊獲取