扫雷核心用二维数组表示格子，元素存未翻开（0）、是雷（-1）或周围雷数（1~8）；初始化全0后随机布雷并去重；首次点击才生成数字；点击0格时用BFS递归展开相邻0区域，配合八邻域偏移和边界检查。
怎么用二维数组表示扫雷的格子和雷区
扫雷最核心的数据结构就是二维数组，它天然对应游戏里横纵排列的格子。每个元素存三种状态：未翻开（0）、是雷（-1）、或周围雷数（1~8）。别用布尔数组或对象模拟——维护成本高、索引慢、边界判断冗余。
初始化时先全填 0，再随机选 mineCount 个位置设为 -1。注意：随机位置必须去重，否则实际布雷数可能少于预期；推荐用 Set 存已选坐标（如 `${r},${c}`），直到大小达标再停止循环。
- 行数列数建议从输入获取，比如
rows = 9,cols = 9，避免硬编码 - 雷数别超过总格子的 25%，否则新手局也容易一戳就炸
- 不要在布雷后立刻计算数字——等玩家第一次点击再生成（避免“开局必死”）
点开一个格子时怎么递归展开空白区域
用户点击一个 0 格子（即周围无雷），需要自动展开所有相连的 0 区域，这是扫雷体验的关键。靠简单 for 循环不行，必须用 DFS 或 BFS。
推荐 BFS：用队列存待处理坐标，每次取一个，检查八邻域。若邻格是 0 且未访问过，就加入队列并标记已访问；若是数字格（1~8），只翻开不入队。这样能自然控制展开边界。
- 邻域偏移用固定数组写死：
[[−1,−1],[−1,0],[−1,1],[0,−1],[0,1],[1,−1],[1,0],[1,1]] - 务必做边界检查：
r >= 0 && r = 0 && c ，否则越界读写会出错 - 已访问状态不能只依赖显示数组（比如用
' '表示翻开），要单独用boolean[][] visited或复用一个标志位，否则重开逻辑混乱
怎么安全地统计每个格子周围的雷数
统计不能等到点击才算——要在布雷完成后、首次点击前一次性算完所有非雷格子的数字。对每个非雷格子，遍历八邻域，数其中 -1 的个数即可。
最容易错的是：在布雷数组上直接改值，导致后续无法区分“原始雷”和“数字”。正确做法是另建一个 board 数组存最终显示值（雷用 *，空用 0，数字用对应整数），而布雷用的 mineMap 始终只存 0 和 -1，保持语义清晰。
- 别用
try/catch捕获数组越界来简化邻域检查——性能差且掩盖逻辑缺陷 - 如果某格本身就是雷（
mineMap[r][c] === -1），跳过统计，board[r][c]直接设为-1 - 统计结果直接赋给
board[r][c]，后续渲染和逻辑都只读这个数组
控制台交互时怎么避免误操作和状态混乱
命令行没有鼠标事件，通常用 “r c” 输入坐标，r 和 c 从 0 开始还是 1 开始？必须统一，并在提示里写清楚，比如 “请输入行 列（空格分隔，从 0 开始）”。否则用户输 1 1 却点中了左上角第二格，会怀疑程序坏了。
关键状态要显式维护：哪些格子已翻开（revealed[r][c] === true）、哪些插了旗（flagged[r][c] === true）。用户输入坐标后，先校验是否在范围内、是否已翻开、是否已插旗——这三步缺一不可，否则重复点同一格会刷新状态或报错。
- 输入解析失败（如非数字、少参数）要给出明确提示，比如 “输入格式错误：请输两个整数”
- 插旗操作建议用单独命令，比如输入
f 2 3，而不是复用同一格式混用动作 - 每次操作后重绘整个棋盘，用
\n分隔行，用.表示未翻开，*表示雷（仅结束时显示），数字直接输出，视觉上才可读
真正的难点不在算法，而在状态同步：布雷数组、数字数组、翻开状态、旗帜状态、用户输入缓冲——它们必须严格一一对应。任意一处脱节，就会出现“看着没雷却炸了”或“明明点了却没反应”的情况。
