必须用两个二维数组：mineMap仅存原始布雷状态（'M'或'0'），showMap仅存玩家可见状态（'#'、'F'、' '或'1'–'8'），二者隔离可避免统计错误、逻辑混乱及标记功能失效。
为什么必须用两个二维数组，而不是一个？
因为雷的位置信息和玩家看到的状态根本不是一回事——混在一起会直接导致逻辑崩溃。比如你用 mineMap 存雷（'M' 表示有雷），但玩家点开后要显示数字或空格，如果还往 mineMap 里写 '1' 或 ' '，那下次统计周围雷数时就会把数字当雷算，或者把空格当无雷漏判。
实操建议：
- 用
mineMap[ROW][COL]仅存原始布雷状态（初始化全为'0'，布雷处设为'M'） - 用
showMap[ROW][COL]仅反映玩家当前可见状态（初始全为'#'，揭开后存数字字符或空格） - 二者完全隔离，所有显示、计数、递归展开都基于这个分工，否则后期加标记（flag）功能时必乱
reveal() 递归展开总卡死或重复访问？检查边界和状态双重判断
递归展开看似简单，但常见错误是没同时拦住「越界」和「已处理」两种情况，结果栈溢出或无限循环。比如只判断 x >= 0 && x ，却忘了 showMap[x][y] != '#' 这一关——一旦某格被递归多次揭开，就会反复调用自己。
实操建议：
- 入口第一句必须是：
if (x = ROW || y = COL || showMap[x][y] != '#') return; - 不要在递归里用全局计数器或外部标志位替代这个判断，容易漏条件
- 如果想避免深递归（比如超大地图），可改用栈模拟，但小规模（9×9）直接递归更直观
边缘格子统计周围雷数总出错？用“冗余边框”比一堆 if 判断更稳
在 countNearbyMines() 中，对 (0,0)、(0,8)、(8,0) 这类角落坐标手动判断邻域，代码又臭又长，还容易漏掉某个 dx/dy 组合。更糟的是，这种写法一换棋盘尺寸就得重改逻辑。
实操建议：
- 定义
#define ROWS (ROW + 2)和#define COLS (COL + 2)，申请mineMap[ROWS][COLS] - 初始化时，把最外一圈全设为
'0'（无雷），真实游戏区从 (1,1) 开始填 - 这样
countNearbyMines(x, y)就能无脑遍历dx ∈ {-1,0,1}、dy ∈ {-1,0,1}，不用任何 if
标记（flag）功能加不上？别动 showMap 的核心状态逻辑
很多人想在 showMap 里用 'F' 表示旗子，结果发现：一标旗就再也无法揭开，或者揭开后旗子消失但逻辑没更新。问题出在没把「标记」当作一种独立状态，而是强行塞进原本只管「揭开/未揭开」的流程里。
实操建议：
- 允许
showMap[x][y]取值为：'#'（未操作）、'F'（已标记）、' '（空格）、'1'–'8'（数字） - 在输入处理环节单独分支：
if (input == 'f') { toggleFlag(x, y); }，不走reveal() -
toggleFlag()只改showMap[x][y]，不碰mineMap，也不触发任何递归
真正难的不是写完能跑，而是让 reveal()、countNearbyMines()、标记切换三者互不干扰。只要数组职责分清、状态枚举完整、递归守好双闸门，剩下的就是调试时多打几行 printf 看中间值——毕竟控制台游戏，没有 UI 层遮掩，逻辑错在哪，一眼就能钉死。
