扫雷这个游戏我估计绝大多数人都玩过但真到自己动手写一个“扫雷游戏布置”的时候才会发现门道比想象中多得多。我最初以为布置就是把地雷随机撒到棋盘上结果一写就踩了一连串的坑首击直接踩雷、边界越界、空白区不连续展开、统计雷数算错……后来把布置逻辑单独拆分出来重构整个项目才顺了起来。这篇文章我就把“布置”这一步从数据模型到界面交互完整拆开讲清楚布雷位置怎么定、数字格怎么算、空白区怎么连锁展开、边界条件怎么处理以及怎么在这个基础上扩展自定义难度、提示辅助、回放这些进阶玩法。适合刚入门游戏开发、想用手写扫雷练算法的新手也适合准备面试想聊清楚扫雷原理的朋友。内容不需要你读完立刻写出一模一样的成品但至少能把布置环节想明白。1. 布置的第一步棋盘数据与布雷位置怎么定1.1 棋盘数据结构用二维数组还是扁平数组很多人写扫雷上来就建一个二维数组这没问题也是我推荐的做法。但有一点要想清楚棋盘上每个格子其实有两层信息一层是“这个格子底下有没有雷、周围有几颗雷”这属于布置阶段的静态数据另一层是“这个格子当前是翻开、未翻开还是被插了旗子”这属于玩家交互阶段的动态状态。我建议把雷信息和状态信息分开存。实际操作中我用的是两个二维结构一个存雷和数字比如board[r][c].has_mine和board[r][c].number另一个存玩家可见状态未打开、打开、旗子、问号。为什么分开因为渲染层和逻辑层不应该混在一起界面只需要读状态来决定画什么图标而判定胜负、统计雷数只看数据层两边互不干扰。这也方便以后做回放——你只需要把状态变化记录下来就行。二维数组的优点是直观board[row][col]天然对应棋盘位置写遍历和判断的时候心智负担最小。缺点是不如一位数组好做内存复用但扫雷这种小游戏根本不需要优化到那一步。扁平数组board[row * cols col]在做序列化、网络传输的时候有优势但代价是每次都要做行列索引换算容易写错。我的经验是新手期或者中小规模棋盘直接二维数组真要做一个超大棋盘且需要频繁序列化的项目再考虑扁平数组。如果用枚举管理状态我习惯这样定义Python 示例class CellState: CLOSED 0 # 未翻开 OPEN 1 # 已翻开 FLAG 2 # 旗子标记 QUESTION 3 # 问号标记状态字段不要用一组 bool 去表示那样判断的时候容易互相打架。比如isFlag和isQuestion同时为 true 就出 bug 了一个枚举字段最干净。雷的数量和位置属于布置结果单独放在mineBoard[r][c]里存布尔值或数字。1.2 随机布雷的三种姿势布雷的核心需求就一句话在rows * cols个格子中随机抽取mineCount个不同位置埋雷。看起来简单但实现方式区别很大。第一种是“遍历每个格子按概率布一颗雷”。也就是生成一个[0, 1)的随机小数小于某个阈值就放雷。这个方案最坑的地方在于这一局到底布了几颗雷完全看运气可能比预设多也可能比预设少。做娱乐项目还好但如果你要做排行榜、难度统计雷数不稳定就非常尴尬。我不会用这个。第二种是“整体坐标随机抽样”。把所有格子的坐标放进一个列表然后随机抽mineCount个不重复的坐标。Python 里random.sample直接能办到其他语言可以用“随机下标 从集合中移除”的思路。这种方法简单可靠适合中小棋盘比如经典初级 9×9、10 颗雷这种规模性能完全没问题。第三种是“Fisher-Yates 洗牌取前 K 个”。把坐标列表当成一副牌用洗牌算法局部打乱然后取前mineCount个。这个方法的好处是既保证不重复又能在棋盘很大的时候只做 K 次交换而不是全部洗一遍效率很高。标准扫雷最大也就 30×24、668 颗雷的规模其实第二种和第三种都绰绰有余。我后来选择的是洗牌思路因为同一套代码可以直接复用到“首击安全区剔除”的场景里。布雷的代码骨架大概长这样import random def random_positions(rows, cols, count, excludeNone): # exclude 是一个 set里面是 (r, c) 需要跳过的格子 all_positions [(r, c) for r in range(rows) for c in range(cols)] if exclude: all_positions [p for p in all_positions if p not in exclude] # 局部洗牌只洗前 count 个位置 for i in range(count): j random.randint(i, len(all_positions) - 1) all_positions[i], all_positions[j] all_positions[j], all_positions[i] return set(all_positions[:count])这里有个容易踩的坑exclude不能写错否则雷数不够或者塞进了安全区。后面首击安全那节我会专门展开。提示当雷数接近格子总数的时候洗牌取前 K 个没问题但exclude之后剩余格子可能不足count要做兜底判断。这个边界我在后面“坑”的部分会再提。1.3 首击安全的公平性问题标准 Windows 扫雷有个非常好的设计第一击永远不踩雷而且通常是直接点开一整片空白。为什么要这样因为扫雷本质是个推理游戏如果开局第一下就靠 1/10 的运气踩雷玩家会觉得不公平尤其是高难度下第一击成功率更低。纯娱乐倒无所谓但要做体验正常的扫雷首击安全必须做。常见的实现方案有三种方案做法优点缺点留空区先根据首击坐标算出一个安全区域本人及其周围 8 格布雷时排除这个区域数据稳定无二次修改安全区偏大时大棋盘雷分布轻微受限移动雷先随机布雷若首击命中雷把该雷移动到随机空白格保留全局随机性首击前后数据会变调试与回放容易暴露雷的位置改规则首击强制直接翻开一个确定的安全格不参与玩家输入实现简单与经典交互不一致体验打折扣我强烈推荐方案一“留空区”这也是我实际用的方案。它思路非常干净玩家点击某个坐标之后把这个坐标的“九宫格”加入exclude集合然后在这个集合以外布雷。代码和上面random_positions的例子天然契合只要把exclude传进去就行。这里补一个很多人没意识到的细节为什么不能采用“先随机布雷首击踩雷后再把雷移走”的方案表面上结果一样但如果你在调试阶段用文本打印棋盘或者以后做回放系统你会看到首击前和首击后棋盘数据发生了改变这相当于把“原本这里有雷”的信息泄露给了开发者甚至是玩家。一旦玩家通过“首击后棋盘变化”反推雷的位置游戏逻辑就失效了。所以我在实现里坚持布雷前就要知道首击位置然后一次性把雷分布确定下来。2. 迷雾之下数字统计与空白区的连锁展开2.1 周边雷数统计把八个方向写成统一循环布雷完成后棋盘上每个格子需要计算出一个数字——周围 8 格里有几颗雷。这个数字就是玩家推理的唯一依据。实现的时候最土的办法是每个方向写一遍if八个方向就八段代码极易写错。我更习惯把八个方向定义成一个方向数组DIRS [ (-1, -1), (-1, 0), (-1, 1), (0, -1), (0, 1), (1, -1), (1, 0), (1, 1), ] def count_mine_around(row, col): count 0 for dr, dc in DIRS: nr, nc row dr, col dc if 0 nr rows and 0 nc cols and mine_board[nr][nc]: count 1 return count有一个非常经典的小技巧把棋盘整体扩一圈也就是在外部加一层永远不会放雷的“围墙”。这样做之后计算数字和判断邻居的时候就不需要每次检查nr、nc是否越界直接访问board[nr][nc]即可因为围墙之外都是空地。代价是内部逻辑里所有坐标都要加一个偏移量比如原来的(0,0)变成(1,1)初始化雷的时候也要注意范围。我个人在中小棋盘上更推荐“越界判断写在循环里”的写法理由只有一个坐标不偏移调试时打印棋盘和玩家看到的坐标一致心智最简单。扩一圈的方案适合那种超大棋盘、性能要求敏感的场景。两种方法我都会但日常项目我选直观的那一种。统计完雷数之后每个非雷格子会得到一个 0~8 的数字。后续玩家点开格子时如果数字是 0就要触发连锁展开如果是 1~8就只显示这个数字。所以你在布置阶段做的事实际上就是给整个棋盘建立一张“数字地形图”。2.2 空白格 flood fill为什么用栈而不是递归扫雷最让人上瘾的体验就是点到一个 0 格瞬间“唰”一下展开一大片。这个连锁展开在算法上叫 flood fill洪水填充规则是如果当前格子是 0就把它的 8 个邻居全部翻开如果邻居中又有 0继续向它的邻居扩展直到遇到数字格为止。新手最容易写出的版本是递归def reveal(row, col): if not valid(row, col) or opened[row][col]: return opened[row][col] True if number[row][col] 0: for dr, dc in DIRS: reveal(row dr, col dc)代码确实简洁但有一个隐患递归深度受棋盘大小和空白区形状影响。标准扫雷 30×24 的棋盘理论上不会爆栈但如果你做自定义超大棋盘或者走到的空白链特别深递归就有风险。另外递归每一层都要保存现场极度深的展开会让肉眼可见地卡顿一下。所以我实际使用的是显式栈def reveal_with_stack(start_r, start_c): stack [(start_r, start_c)] while stack: r, c stack.pop() if not (0 r rows and 0 c cols): continue if cell_state[r][c] CellState.OPEN: continue if cell_state[r][c] CellState.FLAG: # 被插旗的格子不能自动翻开 continue cell_state[r][c] CellState.OPEN # 雷直接跳过胜负在外面判定 if mine_board[r][c]: continue if number_board[r][c] 0: # 只有 0 格才会继续扩散数字格就是递归边界 for dr, dc in DIRS: stack.append((r dr, c dc))这里有个关键细节展开的时候不能只翻 0 的邻居要把 0 周围所有非旗子格子都翻开包括数字格。你回忆一下玩扫雷的体验点开 0 格后周围会出现数字边界。这些数字格不是玩家手动点的是展开时一起翻出来的。如果把判断写成“只对 0 的邻居入栈”就会漏掉这些边界数字格那连锁展开就断了。还有一个细节容易忽略已经被插旗的格子不能自动翻开。因为在标准扫雷规则里玩家如果判断某个格子是雷并插了旗那这个格子的命运只能由玩家自己决定——即使代码知道它是空地也不能替玩家翻开。所以在 flood fill 里必须判断FLAG并跳过。这既是规则要求也是防止“自动展开把你辛苦标记的旗子全翻掉”的糟糕体验。2.3 迷雾状态机和界面数据同步布置阶段其实还隐含了一个设计迷雾状态机。我把每个格子的状态设计成“未翻开 → 翻开”的主线辅以“旗子 / 问号”两个可选状态。在代码里我喜欢用一个枚举字段cell_state来管理它本质上就是玩家眼中的棋盘迷雾。之所以强调状态机和布局数据分离是因为实际开发中很容易出现“界面直接透传雷位置”的错误。比如你图简单在格子的对象上直接写isMine然后界面渲染时调用它这相当于把地雷坐标暴露给了前端。如果玩家通过看控制台或者反编译前端代码就能知道雷在哪——虽然普通玩家不会这么干但对于逻辑健壮性来说是个隐患。正确处理方式是界面层只读cell_state永远不直接访问mine_board。点的格子是不是雷由数据层返回结果界面只负责根据返回值播放翻格子动画、显示数字或触发失败流程。这样以后你做“观战模式”“回放”或者“提示功能”都能在数据层内部搞定不用动界面代码。3. 布置逻辑延伸点击判定与胜负反馈3.1 坐标映射Canvas 绘制与 DOM 网格布置的数据层做完之后要把它接到界面上。这里有两种常见技术路线区别很大用 DOM/CSS Grid 做还是用 Canvas 绘制。DOM 方案最朴素每个格子生成一个button或者div给它们绑定点击事件。9×9 棋盘 81 个节点倒还好30×24 就是 720 个节点数量上来了 DOM 的刷新压力就开始显现。但它最大的优点是事件绑定天然精确哪个格子被点击了事件对象直接告诉你。Canvas 方案正好相反整个棋盘只占用一个画布节点性能好但你需要在点击事件里把像素坐标换算成格子坐标多一道步骤。坐标换算其实不复杂function pixelToCell(offsetX, offsetY, cellSize, boardOriginX, boardOriginY) { const x offsetX - boardOriginX; const y offsetY - boardOriginY; const col Math.floor(x / cellSize); const row Math.floor(y / cellSize); return { row, col }; }boardOriginX和boardOriginY是棋盘左上角在画布上的位置。这一步极其容易踩坑如果你在画布上还画了顶部工具栏、边框、甚至表情按钮那么点击坐标必须先减去这些偏移量否则格子错位。我的调试经验是做完换算函数后立刻在点击处理里打印row, col再在画布上画一个高亮方块比肉眼目测要可靠得多。我个人建议中小标准棋盘先用 DOM把精力放在逻辑正确性上等要做大棋盘、动画或者更复杂特效再迁移 Canvas。逻辑和画面分离后迁移成本不会太高。3.2 三键交互与双击展开扫雷的鼠标交互非常经典左键翻开格子右键标记旗子右键再点变问号然后循环。Web 端实现时要注意的是区分左右键mousedown事件里通过button 0表示左键button 2表示右键。移动端没有右键我通常会做“长按 0.3 秒标记旗子”并且要在touchstart开始计时、touchend时取消防止和页面滚动冲突。比基础交互更进阶一点的是“双击展开”也叫 chord这是高手玩家几乎必用的操作当某个数字格周围的旗子数量已经等于它的数字时双击这个数字格会把周围未标记、未翻开的格子全部一次性打开。这个功能实现核心是一个判断def try_chord_open(r, c): num number_board[r][c] if num 0: return flag_count count_flag_around(r, c) if flag_count num: # 周围未翻开且未插旗的格子相当于执行一次左键翻开 for dr, dc in DIRS: nr, nc r dr, c dc if cell_state[nr][nc] not in (CellState.OPEN, CellState.FLAG): reveal_with_stack(nr, nc)这个功能在布置阶段不算核心但它能检验你的数据结构是否足够清晰。因为要快速统计周围的旗子数、要区分“未翻开”和“插旗”如果你的状态字段是一堆 bool这里就要写一堆组合判断用枚举后一行if flag_count num直接搞定。提示双击展开时如果不小心旗数标错了踩雷概率非常大。所以很多扫雷版本会在展开前做一个“取消动作判定”——周围旗数和数字不相等就什么都不做老实等待玩家修正。3.3 胜负判定与状态重置胜负判定看起来简单写起来容易犯糊涂。很多人的做法是“翻开最后一个非雷格才胜利”这个没问题但具体判断条件要注意效率。我一般维护一个opened_count变量每次翻开非雷格子就1当opened_count rows * cols - mine_count时胜利。这样不需要每次点击都全表扫描棋盘。失败判定就一句话翻开一个mine_board[r][c]为真的格子。失败后的流程稍微讲究一点要把所有雷的位置用爆炸或者红色底显示出来还要把玩家插错旗子的位置打叉最后把整个棋盘的输入状态锁死。重置棋盘是布置逻辑里经常被忽视的一环。最常见的 bug 是“上一局的红旗子还留在新棋盘上”或者“雷数统计混入了上一局的数据”。解决办法很简单重置时直接重建整个数组和状态而不是在旧数组上逐个字段清零。比如 Python 里[[CellState.CLOSED for _ in range(cols)] for _ in range(rows)]重新生成一遍。我见过太多因为反复清零漏掉某个字段而出现的奇怪问题重建是成本最低也最不容易出错的做法。4. 布置时最容易踩的坑4.1 越界处理扩一圈板子可能带来的连锁影响越界是扫雷新手最容易翻车的地方。统计数字要访问 8 个邻居左上角格子的邻居有一半在棋盘外面。两种处理方式各有各的坑不扩一圈的写法里每个判断都要带边界检查。优点是坐标直观缺点是代码里充斥着if 0 nr rows这样的分支看着啰嗦。扩一圈的写法里越界检查全没了但代价是转化为偏移量真正的棋盘从(1, 1)开始到(rows, cols)结束边缘一圈永远存着 0。这个偏移在布雷、渲染、点击换算三个地方都要保持一致漏掉任何一个位置棋盘就会整体错位一个格子。我实际踩过一次这样的坑雷都布在了(0, 0)开始的坐标上而渲染层读的是(1, 1)开始的坐标结果第一行全成了空白边缘雷也显示不出来。排查了很久才发现是偏移不一致。所以我后来写了一个统一转换函数所有逻辑记得调用它而不是在不同层各写一遍自己的坐标公式。4.2 随机可复现种子随机与调试扫雷项目里有一个非常反直觉的痛点随机布雷本身会导致 bug 极难复现。今天跑出来雷在左上角明天可能在右下角想修一个和雷位置相关的 bug可能要跑几十局才能碰上一次。解决方案是给随机数生成器加种子。做法很简单自己写一个带种子的小随机函数或者在项目里设置初始 seed。布置雷的时候用这个种子随机数其他无关紧要的地方比如动画抖动才用系统随机数。有了种子之后你在调试时固定用一个 seed就能稳定复现同一张棋盘一步步打断点查逻辑。排查完再换成时间种子。一个简单可用的伪随机生成器def create_rng(seed): state seed 0xFFFFFFFF def next_random(): nonlocal state state (state * 1664525 1013904223) 0xFFFFFFFF return state / 0x100000000 return next_random种子随机还有一个延伸价值做每日挑战和分享棋盘。你只需要把种子和首击坐标传给对方对方就能复现同一局不需要把整张棋盘序列化传输。这个思路我放在后面进阶玩法里细说。4.3 重置不清空与雷数校验我见过一个高频 bug 是这么来的开发者自定义了 30×20、300 颗雷然后手滑填了个mines 9999。雷数大于总格子数布雷时random.sample直接抛异常或者洗牌取前 K 个时只布了 600 颗雷剩下全是雷区外的空地。所以生成棋盘前必须做参数校验rows、cols都大于 0mine_count在1到rows * cols - 1之间至少要留一个非雷格不然没法赢有首击安全区时安全区大小也要参与计算否则可能出现“排除首击区后剩余格子不够布雷”的极端情况。另一个重置相关的问题是“旧棋盘数组没有彻底丢弃”。如果上一局布了雷这一局你用同一个数组又布一次雷但某个坐标因为逻辑分支没有覆盖到就会出现“明明是新局却残留旧局的雷”这种诡异现象。所以重置逻辑我统一用“重建新数组”而不是“清空旧数组”这个决定替我省掉了很多排查时间。4.4 首击移动雷的隐蔽问题我在前面已经强调了首击安全区方案这里单独把它单独列出来是因为它太容易出隐蔽问题了。假设你采用的是“先布雷首击踩雷后再把雷移动到空格”的方案代码跑起来效果可能还不错但随后你可能会遇到两个问题一是信息泄露。如果你在开发阶段有一个调试面板可以实时打印棋盘你会发现首击前后棋盘不一致。哪怕玩家看不到这个不一致也会让“回放”“观战”这类功能在实现时逻辑很别扭到底以哪个棋盘为准二是移动逻辑本身有顺序问题。你移动一颗雷到随机空格万一这个空格原来也是雷呢你得重新抽。抽完以后受影响的格子周围的数字也要重新计算否则数字提示就错了。我最后一次重构直接换成了“布雷前先收集安全区排除后再布雷”的方案这些问题全部消失。经验就是首击安全属于布置阶段的前置条件而不是事后补救。把安全区当作布雷输入的约束条件来处理整个数据流更干净。5. 进阶布置思路标准扫雷之外的玩法5.1 自定义参数与棋盘生成器标准扫雷有三个难度初级 9×9、中级 16×16、高级 30×16高级其实是 30 列、16 行。但你完全可以做出“自定义棋盘”功能宽度、高度、雷数全部由用户填写生成器负责校验和生成。为了做到这一点我会把布置逻辑封装成一个独立的函数def generate_board(rows, cols, mine_count, first_r, first_c): # 1. 收集首击安全区 safe_zone calc_safe_zone(rows, cols, first_r, first_c) # 2. 排除安全区之后随机布雷 mine_positions random_positions(rows, cols, mine_count, excludesafe_zone) # 3. 初始化数据层 mine_board [[False] * cols for _ in range(rows)] for r, c in mine_positions: mine_board[r][c] True # 4. 统计数字 number_board calc_numbers(mine_board) return mine_board, number_board这样一个函数就能覆盖所有棋盘尺寸不管是标准难度还是自定义参数。它还隐含了一个扩展空间棋盘生成器接口统一之后以后做“地雷密度上限”“保证开局可解”等高级约束只需要往generate_board里加约束逻辑别的模块不用动。另外有一个值得讨论的“可解性”话题标准扫雷并不能保证每一局都能不靠猜通关。如果你追求“完美推理体验”可以在布置阶段加入约束比如“保证首击区域是 0 格”这样玩家开局就有一大片确定安全区。更进一步你可以整局推导一遍如果某个位置无法通过现有信息确定就让生成器调整雷位直到棋盘可解。这个开销不算小但作为进阶玩法很有乐趣。5.2 提示与概率辅助提示功能是布置逻辑的反向操作既然布置阶段生成了雷的准确分布提示就要在不泄露雷位置的前提下从玩家的视角推断出下一步安全动作。最简单的提示是“确定性安全格检测”遍历所有已打开的数字格如果某个数字格周围未翻开的格子数正好等于它剩余需要的雷数且没有旗子说明这些未翻开格子里哪些是雷是确定的反过来如果周围已经插旗的数量等于数字那剩下的未翻开格子就全是安全的可以提示玩家点开其中一个。def find_safe_cell(): for r in range(rows): for c in range(cols): if cell_state[r][c] ! CellState.OPEN: continue if number_board[r][c] 0: continue hidden_neighbors [] flag_count 0 for dr, dc in DIRS: nr, nc r dr, c dc if not in_bounds(nr, nc): continue if cell_state[nr][nc] CellState.FLAG: flag_count 1 elif cell_state[nr][nc] CellState.CLOSED: hidden_neighbors.append((nr, nc)) if flag_count number_board[r][c] and hidden_neighbors: return hidden_neighbors[0] return None # 没有确定性安全格需要猜这个功能的代码量不大但做出来后游戏体验提升非常明显尤其是高难度棋盘中后期。它的核心价值不在于给你开挂而在于帮新手理解扫雷的推理过程——看到提示之后玩家往往能学会“原来这里可以通过旗子数反推”。5.3 分享与回放把一局布置过程序列化前面提到种子随机数进阶玩法里最实用的就是用它实现“分享棋局”。一局扫雷的数据结构其实可以非常小只需要记录rows、cols、mine_count、first_r、first_c和随机种子就能在地图上完整复现出同样的布雷结果。当你和朋友讨论“这一局到底能不能无猜通过”的时候把种子发过去对方打开同一局复盘效率极高。实现上要注意一点整局过程必须确保随机数调用顺序完全一致。第一个随机数用于布雷第二个可能用于移动雷第三个用于第一个提示顺序乱了复现的棋盘就变了。所以我会把随机数对象专门隔离出来并且严格限定“只有棋盘生成阶段调用它”其他任何功能不允许碰这个 RNG。这样一个种子就能稳定复现一局。回放功能在此基础上还能继续扩展可以录制玩家的点击序列然后按时间轴重放。每次点击的目标坐标、状态变化存成数组即可。因为布置数据是可复现的回放时就先用种子重建棋盘再把点击序列一个个执行效果和看录像几乎一样。5.4 移动端适配与视觉主题如果要把扫雷搬到手机上布置逻辑本身不用改但交互细节要重新设计。移动端没有右键所以“长按插旗”几乎是标配。这里有个很容易膈应人的问题长按手势和页面滚动冲突。我的处理方法是触摸开始时记录坐标如果手指移动超过某个阈值比如 10 像素就取消长按只允许滑动页面如果手指基本没动且时间超过 300ms则触发布置旗子。这个逻辑需要单独调试尤其要保证“快速双击”不会被长按误触发。视觉主题属于布置之后的渲染工作但好的主题能极大提高可玩性。我自己做过像素风格的格子、拟物风格的立体按钮、极简扁平风三种其实底层的mine_board和number_board完全没有变化。这个也印证了开头那句话布置逻辑和界面分离做得好换皮就只是一层壳的事。最后聊几句个人体会。扫雷这个项目看起来小但把布置这一层理顺之后我后面加了提示、回放、自定义棋盘、移动端移植全部都很顺利。反倒是早期把逻辑和界面揉在一起写的时候光一个连锁展开就改了好几个版本。如果你正准备动手写扫雷我的建议是先不碰界面用控制台实现完整的数据层并用字符把棋盘打印出来调试——*表示雷数字表示周边雷数#表示未翻开。等逻辑全部跑通再接界面你会发现整个项目写起来非常顺。布置这件事做到位了后面的玩法才会真正好玩起来。