做了这么多年开发我一直觉得扫雷是个特别适合用来练手的项目。表面看不过是一个小游戏可真要动手敲代码你会发现它把数据结构、随机算法、递归遍历、事件处理、 Canvas 渲染这些基本功全串起来了。如果你正在学前端或者想找个项目巩固一下编程思路扫雷绝对比那些抄来抄去的待办清单有价值得多。这篇博客我会从零开始把扫雷这个项目的完整思路、核心算法、代码实现和踩坑记录都写清楚。不光是贴代码我会重点讲清楚每一步为什么这么做。你可以直接照着复现也可以把它当成自己的项目作业来写。我敢说做完这个项目你对怎么把一个需求拆成模块这件事会有完全不一样的理解。1. 项目概述与需求拆解1.1 扫雷的核心业务逻辑扫雷的规则大家应该都清楚一个棋盘上分布着一定数量的地雷玩家左键翻开格子格子上的数字代表它周围八个方向的地雷数量。如果翻开的格子是地雷游戏结束如果格子周围没有地雷游戏会自动扩散翻开一片空白区域。玩家可以在疑似有雷的格子上右键插旗标记防止误点。当你把所有非地雷格子都翻开就算胜利。这听起来不复杂但落到代码层面就要拆出不少子问题棋盘怎么存储、地雷怎么随机分布、数字怎么计算、扩散翻开怎么实现、左右键交互怎么区分、游戏状态怎么管理、界面怎么渲染。每一个子问题都有不同的解决方案而且牵扯到性能和用户体验的权衡。所以做这个项目之前我强烈建议你先坐下来把需求列表写清楚。下面是我当时的原型需求清单支持三种难度初级 9x9 棋盘、10 颗雷中级 16x16 棋盘、40 颗雷高级 30x16 棋盘、99 颗雷支持自定义棋盘大小与雷数左键翻开格子右键切换标记状态插旗/问号/取消标记首次点击绝不能踩雷点击到数字格只翻开当前格点击到空白格要扩散翻开整片区域实时显示剩余雷数和用时游戏结束踩雷或胜利时要有明确状态提示棋盘渲染要清晰数字要用不同颜色区分雷要有视觉辨识度这个清单看起来普通但每条都对应后面一个具体的实现细节。特别是首次点击不踩雷和扩散翻开这两个需求是扫雷的核心体验也是很多初写者在实现时会翻车的地方。1.2 技术选型为什么我用 Canvas 而不是纯 DOM实现扫雷有两种主流方式一种是纯 DOM 操作用 div 网格铺棋盘动态改样式另一种是 Canvas 绘制。我最终选了 Canvas原因很实际。纯 DOM 方案在逻辑上更直观每个格子都是独立元素事件绑定、样式修改看起来很简单。但当你把棋盘规模调到高级的 30x16 也就是 480 个格子时DOM 节点数量会明显拖慢渲染和事件响应。每次翻开大片空白区域批量改样式也会引起多次重排体验不流畅。更重要的是Canvas 方案把所有绘制逻辑集中在一个地方代码结构反而更清晰。用 Canvas 并不是说 DOM 方案无可救药。如果你只做初级难度当练手DOM 方案完全够用而且更容易调试。但从做一个规范项目的角度出发Canvas 能逼你把底层渲染逻辑理顺后面想加动画效果也方便得多。这篇博客的代码就以 Canvas 为主DOM 方案我只会在最后提一下优化思路。1.3 工程结构划分我当时把整个项目分成了三个模块对应三个职责游戏状态模块管理棋盘数据、难度配置、游戏状态准备中/进行中/胜利/失败交互输入模块监听鼠标事件把点击坐标转换成对应的格子坐标渲染模块负责把棋盘状态绘制到 Canvas包括未翻开格子、数字、旗子、地雷等这个划分其实借鉴了 MVC 的思想。但要注意对于扫雷这种规模的项目没必要引入完整框架只要在代码里自觉保持模块隔离就够了。不要把游戏逻辑和渲染逻辑混在一个大函数里不然后面改一个功能就牵一发而动全身。2. 核心算法与数据结构设计2.1 用二维数组还是对象结构棋盘最直观的存储方式是二维数组board[r][c]就能定位到任意格子。每个格子的信息用什么存新手容易犯的错误是把所有属性拆成多个平行数组比如一个数组存地雷位置、一个数组存数字、一个数组存是否翻开。代码写起来全是下标同步维护一旦出错极难排查。正确做法是让每个格子是一个独立对象这样代码的可读性和扩展性都更好。一个格子大概需要这样几个信息const cell { isMine: false, // 是否是地雷 mineCount: 0, // 周围地雷数量 state: covered // covered | opened | flagged | questioned };state字段直接管理格子的显示状态比单独用布尔值控制更清晰。不需要同时维护isOpened、isFlagged等多个布尔值不然状态组合会越来越多逻辑容易打架。初始化棋盘时先按行列生成二维数组填充基础格子。这一步很简单但要注意把每个格子的引用关系理顺。测试的时候随手打印board能直观看到整个数据结构长什么样。2.2 随机布雷的正确姿势布雷最朴素的想法是循环随机取格子然后判断这个格子是否已经有雷有雷就重新随机。这个方案在小棋盘上问题不大但在大棋盘接近雷数上限时很容易陷入死循环性能不可控。更专业的做法是用洗牌算法。把棋盘上的所有格子先按顺序放进一维数组然后做一次 Fisher-Yates 洗牌取前mineCount个格子布雷即可。这样每个格子出现的概率完全均等时间复杂度也是稳定的 O(n)。核心代码大概是这样的function placeMines() { const totalCells rows * cols; const indices []; for (let i 0; i totalCells; i) { indices.push(i); } // Fisher-Yates 洗牌 for (let i totalCells - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [indices[i], indices[j]] [indices[j], indices[i]]; } // 取前 mineCount 个格子布雷 for (let i 0; i mineCount; i) { const index indices[i]; const r Math.floor(index / cols); const c index % cols; board[r][c].isMine true; } }这里的一维索引转二维坐标的公式值得留意r Math.floor(index / cols)c index % cols。如果你把行列搞反后面所有坐标都会错位。我建议这个转换封装成独立函数方便统一调用和测试。2.3 周围雷数计算与边界检查布雷完成后下一步就是计算每个格子周围的地雷数。这个计算逻辑不复杂但边界检查是新手翻车重灾区。直接访问board[r-1][c-1]时如果r或c已经在棋盘边缘数组下标就越界了。处理办法是先把八个方向的偏移量定义成常量然后统一检查目标坐标是否在合法范围内const DIRECTIONS [ [-1, -1], [-1, 0], [-1, 1], [0, -1], [0, 1], [1, -1], [1, 0], [1, 1] ]; function calculateMineCounts() { for (let r 0; r rows; r) { for (let c 0; c cols; c) { if (board[r][c].isMine) { board[r][c].mineCount -1; // 雷格子的数字无意义 continue; } let count 0; for (const [dr, dc] of DIRECTIONS) { const nr r dr; const nc c dc; if (nr 0 nr rows nc 0 nc cols board[nr][nc].isMine) { count; } } board[r][c].mineCount count; } } }这里有个小技巧把地雷格子的mineCount设为 -1这样以后渲染数字、判断翻开逻辑时可以用这个值快速识别地雷。另外要注意数字的范围理论上最大是 8但高级棋盘格子密集很多时候周围一圈全是雷控制好颜色映射表的话数字显示不会出问题。2.4 扩散翻开算法递归与栈的取舍扫雷一个很核心的体验是当你点开一个空白格子周围所有空白区域会一起翻开。这个行为本质是一个图的遍历问题——从当前格子出发沿着没有雷的邻居一直扩散。最直观的实现方式是递归深度优先遍历function floodOpen(r, c) { if (r 0 || r rows || c 0 || c cols) return; const cell board[r][c]; if (cell.isMine || cell.state opened || cell.state flagged) return; cell.state opened; if (cell.mineCount 0) { for (const [dr, dc] of DIRECTIONS) { floodOpen(r dr, c dc); } } }这段代码逻辑很清晰但它藏着一个隐患递归深度。如果棋盘上一大片区域都是空白递归会一层层深入极端情况下可能达到几百上千层直接触发 JavaScript 引擎的调用栈上限导致栈溢出报错。实际开发中我有一个习惯能不用递归就不用递归尤其是遍历深度不确定的场景。这张棋盘的空白扩散就是典型。所以我改成了显式的栈结构用循环替代递归function floodOpen(startR, startC) { const stack [[startR, startC]]; while (stack.length 0) { const [r, c] stack.pop(); if (r 0 || r rows || c 0 || c cols) continue; const cell board[r][c]; if (cell.isMine || cell.state opened || cell.state flagged) continue; cell.state opened; openedCount; if (cell.mineCount 0) { for (const [dr, dc] of DIRECTIONS) { const nr r dr; const nc c dc; if (nr 0 nr rows nc 0 nc cols) { stack.push([nr, nc]); } } } } }两种写法功能完全一样但栈版本的迭代深度由我们自己控制空间占用更可控也不会爆栈。我在后期测试高级难度时特意用全空棋盘验证过很多次栈版本稳得很。3. 核心代码实现与实操过程3.1 游戏初始化流程游戏初始化是整个项目的地基。每次开始新游戏都要依次完成重置棋盘数据、布雷、计算数字、重置计时器和剩余雷数、渲染初始界面。这个流程用代码写就是function resetGame() { board []; openedCount 0; flagCount 0; isGameOver false; isFirstClick true; timerSeconds 0; for (let r 0; r rows; r) { board[r] []; for (let c 0; c cols; c) { board[r][c] { isMine: false, mineCount: 0, state: covered }; } } placeMines(); calculateMineCounts(); render(); updateInfoPanel(); }一个很容易忽略的点resetGame里必须先完整重建board数组而不是只把旧格子改回初始状态。如果复用旧数组可能会出现上次游戏的opened状态残留这样的脏数据。重新分配数组是成本低又最省心的做法。布雷时机这里我先放了placeMines()和calculateMineCounts()说明布雷是在初始化时完成的。后面讲首次点击保护时你会看到这个顺序还需要调整。3.2 棋盘渲染与格子绘制Canvas 渲染的第一步是设置画布尺寸。我建议把格子大小定得宽松一点比如 36 像素这样点击区域大数字和图标也放得下。画布总宽度 列数 x 格子大小总高度 行数 x 格子大小同时要做高分屏适配这个后面单独讲。绘制格子时关键是区分不同状态用不同的颜色和边框让它有立体感。经典扫雷的未翻开格子有明显的凸起边框效果这个效果用两条浅色线和两条深色线就能模拟出来。翻开后的格子则用更浅的底色和细线边框。渲染的完整逻辑大概是function drawCell(ctx, r, c) { const x c * cellSize; const y r * cellSize; const cell board[r][c]; if (cell.state covered || cell.state flagged || cell.state questioned) { // 绘制未翻开格子的立体边框 ctx.fillStyle #c0c0c0; ctx.fillRect(x, y, cellSize, cellSize); ctx.strokeStyle #ffffff; ctx.lineWidth 2; ctx.beginPath(); ctx.moveTo(x, y cellSize); ctx.lineTo(x, y); ctx.lineTo(x cellSize, y); ctx.stroke(); ctx.strokeStyle #808080; ctx.beginPath(); ctx.moveTo(x cellSize, y); ctx.lineTo(x cellSize, y cellSize); ctx.lineTo(x, y cellSize); ctx.stroke(); if (cell.state flagged) { // 绘制旗子 drawFlag(ctx, x, y); } else if (cell.state questioned) { // 绘制问号 drawQuestionMark(ctx, x, y); } } else if (cell.state opened) { // 翻开格子用更浅的底色 ctx.fillStyle #d0d0d0; ctx.fillRect(x, y, cellSize, cellSize); if (cell.isMine) { drawMine(ctx, x, y); } else if (cell.mineCount 0) { drawNumber(ctx, x, y, cell.mineCount); } } }数字的颜色映射是扫雷界的经典配色1 蓝色、2 绿色、3 红色、4 深蓝、5 深红、6 青色、7 黑色、8 灰色。我直接用这个配色会让老玩家一眼觉得很地道。旗子和地雷的绘制用 Canvas 基础路径就能完成这里不展开贴每一行代码但要注意绘制图形时控制好中心点位置否则会明显偏出格子中心。3.3 左键点击与游戏胜负判定鼠标点击事件绑定后要把像素坐标转换成格子坐标canvas.addEventListener(mousedown, (e) { const rect canvas.getBoundingClientRect(); const x e.clientX - rect.left; const y e.clientY - rect.top; const c Math.floor(x / cellSize); const r Math.floor(y / cellSize); if (r 0 || r rows || c 0 || c cols) return; if (e.button 0) { handleLeftClick(r, c); } else if (e.button 2) { handleRightClick(r, c); } });左键点击的处理逻辑要判断几种情况如果游戏已经结束就不响应如果格子是旗子状态就不响应如果还没开始计时就启动计时如果这是第一次点击要先调用首次点击保护逻辑。这些判断的顺序很重要写反了可能出现插旗之后还能点开格子这种低级 bug。function handleLeftClick(r, c) { if (isGameOver) return; const cell board[r][c]; if (cell.state opened || cell.state flagged) return; if (isFirstClick) { handleFirstClickSafety(r, c); isFirstClick false; startTimer(); } if (cell.isMine) { revealAllMines(); gameOver(lose); return; } floodOpen(r, c); checkWin(); render(); updateInfoPanel(); }胜利条件的判定是openedCount rows * cols - mineCount也就是所有非雷格子都已被翻开。这里要注意floodOpen里已经维护了openedCount胜利判断需要在这个计数更新之后进行。3.4 右键插旗与三态切换右键点击的逻辑比左键简单但涉及一个交互细节旗子、问号、无标记三种状态的循环切换。很多扫雷游戏默认只做旗子状态但我建议加上问号状态这是经典扫雷的功能也给玩家提供了不确定先标记一下的选项。function handleRightClick(r, c) { if (isGameOver) return; const cell board[r][c]; if (cell.state opened) return; if (cell.state covered) { cell.state flagged; flagCount; } else if (cell.state flagged) { cell.state questioned; flagCount--; } else if (cell.state questioned) { cell.state covered; } render(); updateInfoPanel(); }剩余雷数的面板显示逻辑是mineCount - flagCount也就是雷数减去已插旗数量。如果玩家插旗位置不对剩余雷数也可能变成负数这是正常现象经典扫雷也是这么处理的。注意preventDefault要加在右键点击事件上否则会弹出浏览器默认的右键菜单这个问题不处理的话每次右键都会被打断。4. 实战中的关键优化与踩坑记录4.1 首次点击保护两种方案怎么选首次点击保护是扫雷的标配功能有两条路可以走。方案一初始化时不布雷拿到第一次点击坐标后再布雷并且排除当前格子以及周围格子。好处是保证首次点击周围绝对安全缺点是雷区分布逻辑被拆成了两段。方案二初始化时正常布雷如果第一次点击踩到雷就把这颗雷移动到另一个安全格子。好处是布雷逻辑保持完整缺点是需要额外的移动逻辑而且安全的定义要考虑周围格子。我实际做下来更推荐方案二因为它的起点更接近真实游戏的随机性——第一次点击触发的扩散翻开效果跟后续翻开的体验一致。但移动雷的时候要重新计算周围格子数字。注意这里必须重新执行calculateMineCounts()否则移动后周围格子的数字就过时了。function handleFirstClickSafety(r, c) { const cell board[r][c]; if (cell.isMine) { // 找到第一个不是雷的格子把雷移过去 for (let i 0; i rows; i) { for (let j 0; j cols; j) { if (!board[i][j].isMine) { cell.isMine false; board[i][j].isMine true; calculateMineCounts(); return; } } } } }这里我简化成了找到第一个安全格子看起来不够严谨。更好的做法是把目标格子设为当前点击格子周围的格子优先。因为如果移动到的格子离点击位置太远首次点击后空白区域可能不扩散体验依然不太自然。不过这个优化属于锦上添花基础版本先用任意安全格子也能跑通。4.2 避免重复刷新造成的性能瓶颈如果渲染函数里每次都把整个棋盘重绘一遍在高级难度下 480 个格子全量重绘其实也不太费力Canvas 的绘制效率足够顶上。但有一个小优化值得做只重绘状态变化的格子或者用一个dirty标志记录需要刷新的区域只有事件触发时才重绘。我当时采用的方式更为直接——每次交互后全量重绘。因为扫雷的格子数量上限只有几百个全量重绘的耗时远低于浏览器的一帧时间做成这样完全不会卡顿。反过来说如果一开始就搞脏矩形之类的优化反而提前引入了复杂度。先把功能跑通确认性能没问题再考虑优化这个节奏更合理。4.3 Canvas 高分屏模糊问题这是 Canvas 绘图老生常谈的问题。如果你的显示器是高分屏直接用canvas.width cols * cellSize会导致绘制出来的棋盘边缘发虚、文字模糊。原因是浏览器在物理像素和 CSS 像素之间做了缩放而 Canvas 默认按 CSS 像素绘制。解决办法是按设备像素比缩放画布的实际尺寸const dpr window.devicePixelRatio || 1; canvas.width cols * cellSize * dpr; canvas.height rows * cellSize * dpr; canvas.style.width cols * cellSize px; canvas.style.height rows * cellSize px; ctx.scale(dpr, dpr);注意ctx.scale只需要在初始化时调用一次之后所有绘制坐标始终保持逻辑像素即可。如果你在每次重绘时重复调用scale会出现绘制整体偏移的怪问题。这个坑我栽过排查了好久才发现是重复缩放导致的。4.4 面板状态同步信息面板上的剩余雷数和计时器是玩家最直观的状态反馈。计时器我用setInterval每秒加一但有一个细节经常被忽略游戏结束后要记得清理定时器。如果不清理计时器还在后台跑下次点重新开始时可能出现两个计时器同时跳动显示时间疯涨的 bug。我习惯把定时器 id 存在一个变量里每次重置游戏时先clearInterval。这个操作虽然简单但属于典型的不看就忘的细节。let timerId null; function startTimer() { if (timerId) clearInterval(timerId); timerId setInterval(() { timerSeconds; updateInfoPanel(); }, 1000); } function stopTimer() { clearInterval(timerId); timerId null; }类似的游戏结束时需要把所有格子状态统一显示出来——踩雷后要展示所有地雷位置同时把误插旗的位置打上叉号这是参与感很强的细节做了之后整个游戏才显得完整。5. 常见问题排查与调试心得5.1 典型问题速查表我在开发过程中积累了不少问题整理成表格方便你直接对照排查。问题现象常见原因解决方案点击格子没反应格子坐标换算错误点击区域偏移打印点击坐标和格子坐标确认换算公式正确右键弹出菜单没有禁止默认事件在contextmenu事件里调用preventDefault()翻开空白格子时页面卡死递归栈溢出或进入死循环检查扩散展开的边界条件改用显式栈遍历首次点击踩雷未做首次点击保护初始化后暂不布雷或布雷后做安全转移数字显示为 0 或异常周围地雷数计算未刷新布雷后确认调用了calculateMineCounts()且顺序正确高分屏画面模糊未做设备像素比适配按window.devicePixelRatio缩放画布计时器重复叠加未清理旧定时器重置游戏时先clearInterval插旗后剩余雷数不变未更新信息面板每次状态变化后都调用updateInfoPanel()胜利后不弹提示胜利判定时机不对确认openedCount更新后再检查胜利条件5.2 当年最让我头疼的一个 bug写扫雷的过程中让我印象最深的是一次迷之卡死。低级难度跑得好好的一到高级难度翻开中间一大片空白区域时页面直接卡住不动。起初我以为是性能问题是 Canvas 重绘太慢导致的。于是做了各种优化甚至把重绘逻辑从全量重绘改成只更新局部问题依旧。最后打印日志才发现问题出在递归的floodOpen上。高级棋盘大片空白区域的递归深度远超我的预期调用栈直接溢出浏览器冻结。把递归改成显式栈后问题立刻消失再没有卡过。这次经历让我养成了一个习惯凡是遍历深度不确定的算法先问问自己能不能用循环替代递归。这个经验放到任何项目里都适用。5.3 调试工具和一些小技巧开发这类项目时我强烈推荐在关键函数入口加日志尤其是坐标转换和状态切换这两个环节。用浏览器开发者工具在floodOpen里打断点然后点开一个空白格子单步走几轮你会看到栈里的坐标如何扩散整个遍历过程一目了然。另一个技巧是把棋盘数据导出到控制台。在mousedown事件里临时打印整个board数组再用开发者工具提供的在内存中保留对象功能就能在控制台里展开数据结构逐个检查。这种做法比肉眼看界面高效得多。还有一个容易被忽略的点调试时把随机布雷换成固定种子也就是用固定的随机序列这样可以复现同一个棋盘。当时我写了一个generateMinesBySeed(seed)函数调试具体问题时用同一局棋盘反复操作效率提升非常明显。如果你想把扫雷做成能对外展示的作品这个能力也能帮你做录屏演示。6. 界面细节与交互体验优化6.1 重新开始与界面切换基础扫雷功能完成之后还有很多细节能让作品真正有成品感。界面布局我采用了上方信息面板加下方棋盘的结构。信息面板左侧显示剩余雷数右侧显示计时器中间放一个重新开始按钮。按钮不只是触发resetGame还应该让界面状态同步切换。比如按钮的表情或图标可以随游戏状态变化经典扫雷里这个按钮就是一张小脸游戏过程中会随状态变化我觉得这个交互很有意思也照着实现了。难度切换一般通过下拉菜单或按钮组实现。每次切换难度除了重置棋盘数据还要重新计算画布尺寸因为不同难度的行列数不一样。这里提醒一下如果画布尺寸变了canvas.width和canvas.height要重新赋值并且要重新调用一次ctx.scale(dpr, dpr)。否则在高分屏上切换难度之后画面会突然变模糊或者文字变小又得排查半天。6.2 双击排雷与和弦操作经典扫雷还有一个效率功能双击一个已翻开的数字格如果周围旗子数量等于该数字会一次性翻开周围所有未标记的格子。这个功能叫 Chord中文常叫双击排雷。实现思路是function handleChord(r, c) { const cell board[r][c]; if (cell.state ! opened || cell.mineCount 0) return; const neighbors getNeighbors(r, c); const flaggedNeighbors neighbors.filter(([nr, nc]) board[nr][nc].state flagged); if (flaggedNeighbors.length ! cell.mineCount) return; for (const [nr, nc] of neighbors) { const neighbor board[nr][nc]; if (neighbor.state covered) { if (neighbor.isMine) { // 双击排雷猜错了踩雷失败 revealAllMines(); gameOver(lose); return; } floodOpen(nr, nc); } } checkWin(); render(); }这个功能看上去是锦上添花但如果你打算用扫雷做面试作品加上这个交互能明显展示你对用户体验的理解深度。唯一要小心的是双击事件和两个单击事件之间的触发次序问题。我当时的做法是监听dblclick事件但在它触发之前两次单击已经各自执行了一次handleLeftClick。需要用一个计时标志把第一次单击动作延迟到双击判定之后这个细节比较简单但处理不好会毛躁。6.3 暗黑模式与视觉风格所有功能做完之后可以顺手做一个暗黑模式。扫雷的经典灰白色调看久了确实有点审美疲劳。我当时实现了一个配色变量表把背景、格子凸起、数字颜色、雷的颜色全部抽成变量通过一个theme对象切换。这样做的好处是主题切换只是改一套颜色配置绘制逻辑一行不动。具体的配色方案我不贴了你可以按自己审美来。但有一点提醒数字颜色在深色背景下要把经典扫雷的 1-8 颜色全部重新调整一遍浅蓝、浅绿这类颜色在深色背景上的可读性极差。我当时吃了这个亏后来把所有数字颜色都换成了高亮色系才解决。7. 扫雷项目的终极价值最后说点我自己的感受。扫雷这个项目最打动我的地方是它既小又完整。它需要的代码量不大哪怕从零写起也就几百行但它蕴含的知识点密度极高随机性处理、边界条件、图的遍历、事件系统、Canvas 绘制、状态管理、性能优化、用户体验设计几乎每一个环节都有值得深挖的细节。做完这个项目后你完全可以把它扩展成更多玩法。比如加一个自动求解器用约束传播推理出必然安全或必然有雷的格子或者把棋盘渲染换成 WebGL 来支持超大尺寸地图也可以接一个后端排行榜把通关时间传到服务器上。这些都是很好的进阶方向不过前提是把基础版本做得足够稳健。如果你也在写扫雷或者想拿它练手建议你不要急着抄代码先自己把数据结构和关键算法想清楚卡住了再看我的讲解。踩坑本身就是做项目最有价值的收获。等到你亲手把最后一块棋盘绘制出来、第一次完整通关的时候那个成就感跟看教程完全不是一回事。