企业官网建设流程全解析

我最早接触扫雷还是在PC上，那时候的Windows系统自带游戏，简简单单一个格子面板却总能让人一玩就是一下午。后来做移动端开发，接触了Flutter，又陆续研究OpenHarmony的生态，一个念头就很自然地冒出来：能不能把扫雷这类经典小游戏搬到一个自研的游戏集合App里，顺便验证一下Flutter在OpenHarmony上的工程能力？这个项目就这么立项了，而整个开发过程中最考验UI基本功的，恰恰是“数字显示”这个看似不起眼的功能。

这篇文章就围绕“Flutter for OpenHarmony游戏集合App实战之扫雷数字显示”展开，我会把扫雷的数字从生成、计算到渲染的完整链路拆开讲，包括数据模型怎么设计、数字背后的8邻域算法怎么写、UI怎么选型、动画怎么做，以及在这套技术栈上踩过的坑。适合对Flutter有一定基础、同时又对OpenHarmony跨端开发感兴趣的读者，当然，如果你只是想把扫雷这个小游戏做扎实，里面的大部分方案也是通用的。

1. 项目整体设计与思路拆解

1.1 为什么第一个模块选扫雷

游戏集合App的模块可以有很多选择，俄罗斯方块、贪吃蛇、五子棋、消消乐，哪个不比扫雷看起来“热闹”？但我最后还是把扫雷定为第一个模块，原因其实很实际：扫雷是最适合验证框架能力的2D网格游戏。

扫雷的核心交互是“点一下格子，根据数字推理出地雷位置”。它需要的技术能力覆盖了Flutter开发的几个核心面：网格布局（GridView或者自定义布局）、手势处理（点击、长按区分）、状态管理（格子状态的流转）、条件渲染（翻开数字与旗帜的不同视觉）、动画效果（翻开时的过渡）。把这些能力在一个模块里跑通，后续再往集合App里加俄罗斯方块、黑白棋这些模块时，底层的架构和经验都可以直接复用。

而且扫雷的规则极其简单，不需要美术资源和复杂的音频设计，一个人从零开始写，一个周末就能跑通核心玩法。它不像俄罗斯方块那样依赖固定帧率的主循环，也不像物理游戏那样需要引擎级支持，对OpenHarmony这种新兴平台来说，越少依赖平台能力，兼容性问题就越少。所以我把它当作整个App的“试金石”。

1.2 数字显示在整个扫雷里的位置

扫雷的“数字显示”听起来像是一个很小的UI点，实际做起来才发现它是整个游戏从逻辑到界面的关键枢纽。

先理清扫雷的规则：翻开一个格子，如果格子下面是地雷，游戏结束；如果是空白格，它会显示周围8个格子中地雷的数量，也就是数字1到8；如果周围没有地雷，则显示空白并自动递归翻开周围的格子。所以数字不是随便画上去的，它承载了三层信息：这个格子已经翻开了、周围有雷、周围具体有几个雷。

从数据层看，数字来自布雷后的邻域计算，这是游戏逻辑的核心之一。从UI层看，数字的颜色、位置、比例直接影响游戏的可读性，玩过扫雷的人都知道，数字的颜色是强记忆点：1是蓝色，2是绿色，3是红色，4是深蓝，这些颜色帮助玩家快速分辨数字大小。从交互层看，当玩家点开一个已经翻开的数字格时，如果周围旗帜数量等于该数字，会触发“chord”（连带翻开）操作，一次性翻开周围所有非旗帜格子，而这个操作的触发条件判断就依赖于数字。

所以数字显示做得好不好，决定了扫雷玩起来是“流畅推理”还是“一脸懵”。这也是我写这篇文章想重点展开的部分。

1.3 技术选型上的考量

这个项目的技术路线是Flutter for OpenHarmony。为什么要用Flutter而不是其他方案？

OpenHarmony支持多种应用开发方式，有ArkTS声明式开发，也有C++的Native开发，还有兼容Android的Java/Kotlin方案。但我的目标很简单：同一套代码，既能跑在OpenHarmony上，也能在未来很方便地回到Android/iOS，或者做桌面端的适配。Flutter在这方面天然有优势，UI层完全自绘，一套Dart代码可以跨平台复用。

扫雷这种游戏本质上不需要太多平台特有能力，基本就是Canvas绘制、手势输入和计时器，这正好是Flutter的舒适区。相比较而言，如果用ArkTS原生写，虽然和OpenHarmony系统结合最紧密，但代码就跟Android平台的Kotlin绑定了，未来换平台基本要重写。而Flutter for OpenHarmony是社区维护的分支，SDK层面的适配已经比较成熟，hap包构建、真机调试这些流程都能走通。

当然，选型也不是没有代价。OpenHarmony的Flutter分支在插件生态上还没有Android/iOS那么丰富，部分第三方库要手动适配。好在这个游戏集合App几乎不依赖平台插件，需要用的功能Flutter框架层都自带，所以风险完全可控。

2. 扫雷核心逻辑：数字是怎么算出来的

2.1 格子数据模型设计

数字显示的第一步不是画UI，而是把数据模型设计好。扫雷的棋盘本质上是一个二维数组，我把它定义成Cell类：

enum CellState { hidden, // 未翻开 revealed, // 已翻开 flagged, // 已标记旗帜 questioned, // 标记问号（可选） } class Cell { final int row; final int col; bool isMine = false; // 是否是地雷 int adjacentMines = 0; // 周围地雷数，决定显示数字 CellState state = CellState.hidden; Cell(this.row, this.col); }

这里有个容易忽视的细节：adjacentMines只有在格子不是雷的时候才有意义，如果格子本身是雷，这个字段可以不用管。但在初始化时我还是把它统一赋值为0，避免读取时出现空安全的问题。

棋盘用一个二维List保存：List<List<Cell>> board。我建议不要用一维数组加下标换算，虽然代码上更紧凑，但扫雷逻辑里经常需要判断“某个坐标的邻居”，二维数组的语义更直观，排查问题也方便。后续优化性能时再考虑拍平到一维也不迟。

2.2 布雷算法与首点保护

布雷逻辑是所有数字计算的源头。业界经典的布雷方式是洗牌法：把棋盘所有格子的索引放进一个列表，随机打乱，然后取前mineCount个格子作为地雷。

我用的方式类似，但增加了一个非常重要的处理：首点保护。玩家第一次点击的格子及其周围8个格子不能有雷，否则第一下就踩雷，体验极差。这个需求看起来简单，但实现时有个小坑：如果地图很小而雷很多，比如9x9的棋盘有10个雷，首点保护后剩余的可用格子可能刚刚够放雷，所以逻辑上要先计算安全区，再从候选区里选雷。

void placeMines(int firstRow, int firstCol) { // 首点保护：firstRow/firstCol 周围 3x3 区域不布雷 final safeZone = <int>{}; for (var dr = -1; dr <= 1; dr++) { for (var dc = -1; dc <= 1; dc++) { final r = firstRow + dr; final c = firstCol + dc; if (r >= 0 && r < rows && c >= 0 && c < cols) { safeZone.add(r * cols + c); } } } final candidates = <int>[]; for (var i = 0; i < rows * cols; i++) { if (!safeZone.contains(i)) { candidates.add(i); } } candidates.shuffle(Random()); var placed = 0; for (final index in candidates) { if (placed >= mineCount) break; final r = index ~/ cols; final c = index % cols; board[r][c].isMine = true; placed++; } }

这里我做了个细节优化：先用safeZone集合存安全格子的索引，再用一次循环生成候选列表，这样避免在洗牌后再逐个过滤导致的地雷数量不足问题。很多新手实现首点保护时，习惯先布雷再检查首点是否是雷，不是雷就重新洗牌，这种做法在棋盘小、地雷密的时候可能死循环或效率极差，建议直接采用排除法。

2.3 邻域计数与翻开联动

布雷完成后，就要计算每个非雷格子周围的数字。这个逻辑没有捷径，就是遍历8个方向，逐个判断是否越界、是否是雷：

void calculateAdjacentMines() { for (var r = 0; r < rows; r++) { for (var c = 0; c < cols; c++) { if (board[r][c].isMine) continue; var count = 0; for (var dr = -1; dr <= 1; dr++) { for (var dc = -1; dc <= 1; dc++) { if (dr == 0 && dc == 0) continue; final nr = r + dr; final nc = c + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && board[nr][nc].isMine) { count++; } } } board[r][c].adjacentMines = count; } } }

这个双层循环的时间复杂度是 O(rows x cols x 8)，对于扫雷这种最大也就 16x30 的棋盘来说，性能完全不是问题。我在开发初期还曾经想过用卷积核或者预计算前缀和来优化，后来发现完全没必要——棋盘规模决定了暴力遍历就是最优解，可读性还更好。

翻开逻辑是整个数字显示的核心联动。当玩家点击一个格子，如果它是空白格（adjacentMines == 0），需要自动向四周扩散翻开，直到遇到有数字的格子为止。这一步用深度优先搜索（DFS）或广度优先搜索（BFS）都可以实现。我用的DFS递归，代码更简洁：

void revealCell(int row, int col) { final cell = board[row][col]; if (cell.state == CellState.revealed || cell.state == CellState.flagged) { return; } cell.state = CellState.revealed; revealedCount++; // 空白格自动展开 if (cell.adjacentMines == 0 && !cell.isMine) { for (var dr = -1; dr <= 1; dr++) { for (var dc = -1; dc <= 1; dc++) { if (dr == 0 && dc == 0) continue; final nr = row + dr; final nc = col + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols) { revealCell(nr, nc); } } } } }

这里有个值得注意的地方：递归在棋盘很大的时候可能会有栈溢出的风险，但扫雷棋盘最高不超过480个格子（16x30)，递归深度完全可控。如果未来你把它扩展到超大棋盘，就需要改成显式的Stack迭代或者用队列做BFS。

2.4 chord操作：数字的高级交互

扫雷高手一定不会不知道chord操作：在一个已经翻开的数字格上，如果周围旗帜数量等于这个数字，双按或同时按左右键，可以自动翻开周围所有未标记旗帜的格子。这个功能极大提升游戏效率，也让数字显示在交互层面有了更深的含义。

实现chord操作的关键在于“先验证旗帜数量，再批量翻开”。我写了一个独立的触发方法：

void chordCell(int row, int col) { final cell = board[row][col]; if (cell.state != CellState.revealed || cell.adjacentMines == 0) return; var flagCount = 0; for (var dr = -1; dr <= 1; dr++) { for (var dc = -1; dc <= 1; dc++) { if (dr == 0 && dc == 0) continue; final nr = row + dr; final nc = col + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols) { if (board[nr][nc].state == CellState.flagged) { flagCount++; } } } } if (flagCount == cell.adjacentMines) { for (var dr = -1; dr <= 1; dr++) { for (var dc = -1; dc <= 1; dc++) { if (dr == 0 && dc == 0) continue; final nr = row + dr; final nc = col + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols) { if (board[nr][nc].state != CellState.flagged && board[nr][nc].state != CellState.revealed) { if (board[nr][nc].isMine) { gameOver(); // 旗帜标错了，踩雷 return; } revealCell(nr, nc); } } } } } }

这个功能在移动端的实现有个交互层面的问题：移动设备没有双键同时按，所以我在数字格上做了一个双击手势，用GestureDetector的onDoubleTap来触发chord。开发时还要注意一点：如果双击数字格之前系统把第一次点击也当作了一次普通翻开，就会引发状态冲突。我的处理方式是，在数字格上屏蔽单击翻开，只保留双击chord，这样交互语义更清晰。

3. 数字显示的UI实现细节

3.1 数字渲染方案的选型

数字显示是扫雷UI的重头戏。Flutter里渲染数字有几种常见方案，我一开始列了个对比表，反复权衡后才确定最终方案：

我的结论是：扫雷的网格通常在 9x9 到 16x30 之间，最多也就480个格子，远远达不到Flutter Widget树的性能瓶颈，用Text组件完全没问题。而且Text组件天然支持富文本、字体复用和无障碍语义，团队后续维护的成本最低。所以我最终选择用Text作为基础，但在顶部信息栏的“七段数码管”部分使用CustomPaint自绘，这个稍后详细说。

数字格子的UI我封装成一个独立的Widget，叫CellView，它根据Cell的state和adjacentMines来决定渲染样式，这样UI和逻辑的耦合度很低，修改样式时不会碰逻辑层。

3.2 经典配色的还原

扫雷数字的颜色是有“记忆点”的。玩过经典Windows扫雷的玩家，看到蓝色1、绿色2、红色3，肌肉记忆立刻就被唤醒了。我在还原配色的过程中，特意对照了经典版本的视觉规范：

这里要注意一个细节：数字8的颜色不是最深的，而是灰色，因为8代表“周围全是雷”，视觉上应该给人一种“信息最多”的密集感，用高亮色反而抢戏。数字3用红色，则是因为它在推理中出现的频率高，红色最容易引起注意，提醒玩家优先处理。这些设计心理学层面的考量，让经典配色不仅仅是一种“复古怀旧”，更是一种经过验证的可用性设计。

在Flutter里实现配色映射很简单，我用一个静态Map：

const Map<int, Color> mineNumberColors = { 1: Color(0xFF1963D6), 2: Color(0xFF0E9F44), 3: Color(0xFFD0312D), 4: Color(0xFF2E4E9E), 5: Color(0xFF8B1A1A), 6: Color(0xFF2E8B8B), 7: Color(0xFF1A1A1A), 8: Color(0xFF808080), };

3.3 格子状态机的视觉表达

数字显示不只包括“数字本身”，还包括数字出现之前的格子外观状态。一个未被翻开的格子、一个被插了旗帜的格子、一个显示数字的格子，在视觉上和交互上必须有足够明显的区分。

我定义了四种格子外观：

• 未翻开：凸起的灰色方块，模拟老式扫雷的立体按钮效果。Flutter里我用Container加BoxShadow来做凸起：

Container( decoration: BoxDecoration( color: const Color(0xFFBDBDBD), border: Border.all(color: const Color(0xFF7B7B7B), width: 0.5), boxShadow: [ BoxShadow( color: Colors.white.withOpacity(0.8), offset: const Offset(-1.5, -1.5), blurRadius: 0, ), BoxShadow( color: Colors.black.withOpacity(0.25), offset: const Offset(1.5, 1.5), blurRadius: 0, ), ], ), )

• 已翻开数字：凹下去的浅灰背景，数字按adjacentMines选择颜色居中显示。
• 旗帜：用红底白字或一个旗帜图标，我为了减少依赖，直接在格子里画一个小旗子：红色三角形加竖线，用CustomPaint实现，避免加载图片资源。
• 问号：标记为问号的格子表示“不确定”，展示为灰色背景上的黑色问号，视觉上比旗帜更弱一些。

这里有一个我一开始忽略的细节：翻开格子的背景色和未翻开格子的背景色必须有一个从“凸起”到“凹陷”的视觉转变，否则玩家会分不清哪些格子已经点过了。我在实现时让翻开的格子背景色改成更深的0xFFE0E0E0，同时去掉左上角的白色高光，保留右下角阴影，这样层级感就出来了。

3.4 数字翻开动画的实现

数字显示不应该只是“啪”一下直接出现，一个自然的“弹入”动画能让整个游戏的手感提升一个档次。我当时给格子翻开做了两个动画效果：

第一个是缩放入场：数字从0.5倍缩放到1.0倍，同时透明度从0到1。用Flutter的AnimatedScale和AnimatedOpacity组合实现：

AnimatedScale( scale: cell.state == CellState.revealed ? 1.0 : 0.5, duration: const Duration(milliseconds: 120), curve: Curves.easeOutBack, child: AnimatedOpacity( opacity: cell.state == CellState.revealed ? 1.0 : 0.0, duration: const Duration(milliseconds: 80), child: Text( '${cell.adjacentMines}', style: TextStyle( color: mineNumberColors[cell.adjacentMines], fontSize: 18, fontWeight: FontWeight.bold, ), ), ), )

第二个是按下反馈：用手指点击未翻开的格子时，格子会有一个轻微的“按下去”动画，模拟实体按钮按下再弹起。这个用GestureDetector的onTapDown和onTapUp状态控制即可，让交互有物理感。

动画设计中要特别注意的是：大规模翻开（也就是点开一个空白格后，周围几十个格子同时翻开）时，如果让每个格子都延迟播放动画，整体视觉会很乱。我当时的处理是：空白格扩散翻开时取消动画，直接显示最终状态，只有玩家单点翻开带数字的格子时才播放动画。这样既保留了关键交互的反馈感，又避免了大面积翻开时的闪屏。

3.5 顶部信息栏的七段数码管

扫雷除了雷区中央的数字，顶部信息栏还有两个经典的数字显示：剩余雷数计数器和计时器。它们用红色七段数码管风格显示，用来还原老街机的那种质感。我用CustomPaint实现了这个七段数码管。

七段数码管的原理是把一个数字拆成7个“段”（a到g），每个数字点亮不同的段位组合。我定义了一个段位映射：

const Map<int, List<String>> sevenSegmentMap = { 0: ['a', 'b', 'c', 'd', 'e', 'f'], 1: ['b', 'c'], 2: ['a', 'b', 'g', 'e', 'd'], 3: ['a', 'b', 'g', 'c', 'd'], 4: ['f', 'g', 'b', 'c'], 5: ['a', 'f', 'g', 'c', 'd'], 6: ['a', 'f', 'g', 'e', 'c', 'd'], 7: ['a', 'b', 'c'], 8: ['a', 'b', 'c', 'd', 'e', 'f', 'g'], 9: ['a', 'b', 'c', 'd', 'f', 'g'], };

绘制时，在CustomPaint的paint方法里根据映射点亮对应段：

class SevenSegmentPainter extends CustomPainter { final int value; final Color activeColor; final Color inactiveColor; SevenSegmentPainter({required this.value, required this.activeColor, required this.inactiveColor}); @override void paint(Canvas canvas, Size size) { final paint = Paint() ..style = PaintingStyle.fill; final segments = sevenSegmentMap[value] ?? []; final segWidth = size.width * 0.15; // 定义各段的路径（略） // 这里用 Rectangle 简化为示例 void drawSegment(String name, Rect rect) { final visible = segments.contains(name); paint.color = visible ? activeColor : inactiveColor.withOpacity(0.15); canvas.drawRRect( RRect.fromRectAndRadius(rect, Radius.circular(1)), paint, ); } // a段：顶部横线 drawSegment('a', Rect.fromLTWH(segWidth * 2, 0, size.width - segWidth * 4, segWidth * 0.6)); // b段：右上竖线 drawSegment('b', Rect.fromLTWH(size.width - segWidth * 0.8, segWidth, segWidth * 0.6, size.height / 2 - segWidth)); // 其他段类似... } @override bool shouldRepaint(covariant SevenSegmentPainter oldDelegate) { return oldDelegate.value != value || oldDelegate.activeColor != activeColor; } }

这个面板的实现让顶部显示非常还原老扫雷的风格，同时也是项目里一个很棒的“数字显示”例子：同样是数字，但用途、风格、绘制方式可以和棋盘里的数字完全不同。

顶部计数器的逻辑也不复杂：剩余雷数 = 总雷数 - 当前插旗数。当玩家插旗时递减，拔旗时递增。显示范围限制在0到999之间，超出则显示999，我一开始没有做这个裁切，结果旗子插得比雷还多的时候，计数器出现了个位数和百位数的多段闪烁，排查半天才发现是取模逻辑写错了。

4. Flutter for OpenHarmony 的搭建与踩坑

4.1 环境准备：SDK与工具链

OpenHarmony上的Flutter开发，最核心的一步是SDK选型。这里要说明：OpenHarmony官方并没有像Android那样把Flutter作为一等公民支持，Flutter for OpenHarmony是社区维护的分支，版本节奏会比官方Flutter慢一些。我当时采用的是社区发布的OpenHarmony 4.0兼容分支。

环境准备的大致步骤是：

1. 准备OpenHarmony SDK，用DevEco Studio作为IDE。
2. 下载Flutter的OpenHarmony分支SDK，配置到环境变量里。
3. 配置FLUTTER_STORAGE_BASE_URL环境变量，指向国内镜像地址（这一步国内开发者必不可少，否则依赖下载会非常慢）。
4. 用flutter doctor验证环境是否正常。

这里有一个比较大的坑：Flutter项目默认的.gitignore和构建产物机制在OpenHarmony上不完全适用。OpenHarmony的构建产物是hap包，需要用sdk里的工具链进行签名，不像Android可以直接生成debug包安装。开发阶段我们可以用flutter run配合开放的签名配置来调试，但上架前正式签名流程还是要走一遍。

4.2 工程改造与hap构建

创建OpenHarmony的Flutter工程，官方推荐还是用flutter create命令创建标准Flutter工程，然后手动添加OpenHarmony平台目录。我当时执行的命令是：

flutter create --org com.example.minesweeper --project-name mine_sweeper_app .

然后在工程根目录执行flutter build hap --debug或者--release来构建OpenHarmony应用包。这里要注意：flutter build hap是OpenHarmony分支特有的命令，官方Flutter SDK是没有这个能力的，所以如果不小心切回了稳定分支，命令会直接报错。

构建过程中，我遇到过一个典型问题：You are applying Flutter's main Gradle plugin imperatively using the apply method这个警告。它指的是项目里的Gradle配置还在用老式方式应用Flutter插件。在OpenHarmony分支中，推荐使用声明式插件应用方式，我修改了工程下的build.gradle文件，把插件声明改为：

plugins { id "com.huawei.ohos.plugin.flutter" }

这个调整之后，构建产物就正常了。大家在网络搜索这个提示时，能看到大量相关讨论，但一定要记得结合自己用的分支版本去处理。

4.3 真机调试的关键差异

真机调试是我在这个项目里花时间最多的部分。

首先，连接OpenHarmony设备不能使用adb，而是要用hdc（OpenHarmony Device Connector）工具。它和adb的用法非常相似，常用命令有hdc list targets查看设备列表、hdc shell进入设备shell、hdc file send推送文件。我记得第一次运行flutter run时，终端提示找不到设备，排查了一圈才发现是hdc工具的版本和OpenHarmony系统版本不匹配，重新配置工具链后问题解决。

其次，OpenHarmony的Flutter分支在渲染引擎上仍然以Skia为主，Impeller引擎的适配还在推进中。实际跑起来后，我发现简单的扫雷界面在Skia渲染下完全流畅，但如果你要做大规模粒子效果的动画，可能就要等Impeller在OpenHarmony上稳定了。这个我们在开发时已经用“翻牌动画复杂度控制”做了规避，避免UI层过度消耗渲染性能。

最后是包体积问题。Flutter for OpenHarmony构建出来的hap包会比Android APK略大，因为带了一套完整的Flutter引擎。我实测下来，一个最简单的扫雷App，release包大约在15MB到20MB之间，在OpenHarmony生态里算中等体积，可以接受。如果后续要做上架发布，建议开启--split-debug-info和--obfuscate两个参数，能有效减少包体并增强代码安全性。

5. 常见问题与排查技巧实录

5.1 深色模式下数字“消失”

项目初期，我在系统设置为深色模式的设备上测试，发现扫雷棋盘上的数字几乎看不清：数字1的蓝色在深色背景下对比度骤降，深色背景下的灰色格子和灰色数字混成一片。

问题的根源在于，我的CellView没有对深色模式做适配。解决方案有两个思路：一是强制游戏界面始终使用浅色主题，因为扫雷的经典视觉就是浅色棋盘，深色模式下也保持这个设计不会显得突兀；二是给棋盘设计一套深色主题的数字配色。

我最终选择了方案二，理由是这个游戏集合App未来会有多款游戏，全局主题统一以后，单款游戏不能随意破坏系统主题连贯性。深色主题的数字配色需要提高颜色的亮度，比如数字1从深蓝0xFF1963D6调亮到0xFF4F8DFF，数字3从红色调亮到亮红。实现时我用一个isDarkMode标志位，在构建颜色映射时做切换。记住一个原则：数字显示的可读性永远优先于“复古还原”。

5.2 快速点击导致的界面错乱

扫雷游戏里有个经典操作场景：玩家在短短几秒内快速点击多个格子，甚至对同一个格子连点两下。这在逻辑层带来一个隐患：revealCell方法在异步回调里检查了格子状态，但两个点击事件可能在同一个状态快照上同时操作，导致棋盘出现“重复翻开”或者“明明标记了旗帜却还能翻开”的错乱。

排查后发现，问题出在我的手势层是独立于逻辑层的，没有加锁机制。解决方法是：给逻辑层加一个简单的操作标志位isProcessing，当一次点击处理完成前，屏蔽后续点击事件。同时把格子状态检查前置到点击事件入口，而不是放到revealCell内部：

void onCellTap(Cell cell) { if (isProcessing || gameOver || gameWin) return; if (cell.state != CellState.hidden) return; isProcessing = true; try { if (cell.isMine) { gameOver(); } else { revealCell(cell.row, cell.col); } } finally { isProcessing = false; } }

这样既能防止连点错乱，也为后续动画和状态刷新留出了缓冲时间。实测下来，连续快速点击格子，界面表现稳定多了。

5.3 首点踩雷体验差

首点保护我一开始就加了，但开发中发现了一个边界场景：如果在玩家第一次点击后，通过“重新开始”功能开始新一局，第一次点击又会被当作首点处理，这本是正确的。但如果玩家在第一次点击后，又开了“自定义难度”并修改了棋盘大小，安全区的计算尺寸和新棋盘不一致，就会导致首点照样踩雷。

这个问题的本质是：新棋局重置时，没有同步重置“首次点击”标志。我的做法是，在resetGame()方法里将isFirstMove重置为true，同时确保棋盘尺寸变化时，placeMines里的安全区计算使用最新的rows和cols。玩扫雷的老玩家对首点保护非常敏感，这个细节值得反复测试。

5.4 计时器在App退到后台后继续计时

扫雷的计时器逻辑：游戏开始后每秒刷新一次顶部七段码显示。但在OpenHarmony上，App切到后台再回到前台时，计时器可能会出现两个问题：一是计时器线程被系统挂起，恢复前台后时间跳跃；二是计时器继续运行，导致游戏时间虚高。

正确的做法是在App生命周期回调中暂停和恢复计时器。标准Flutter工程里，用WidgetsBindingObserver监听AppLifecycleState即可：

@override void didChangeAppLifecycleState(AppLifecycleState state) { if (state == AppLifecycleState.resumed) { timer?.start(); } else if (state == AppLifecycleState.paused || state == AppLifecycleState.inactive || state == AppLifecycleState.hidden) { timer?.stop(); } }

OpenHarmony分支对生命周期状态的支持和Android一致性很好，只要在State类里正确注册WidgetsBinding.instance.addObserver(this)，就能稳定收到状态回调。这个坑如果不及时处理，用户玩一局50秒的游戏，可能因为切出去回个微信，结束时就变成了5分钟，非常影响体验。

5.5 不同分辨率下的布局适配

扫雷的棋盘是固定行列数的网格，但不同设备的屏幕宽高比差异很大。我在项目早期用固定边长渲染格子，结果在平板设备上格子巨大，在窄屏手机上又挤成一团。解决方案是：根据屏幕可用尺寸和棋盘行列数动态计算格子边长。

final screenWidth = MediaQuery.of(context).size.width; final screenHeight = MediaQuery.of(context).size.height; final boardPadding = 8.0; final availableWidth = screenWidth - boardPadding * 2; final availableHeight = screenHeight - appBarHeight - infoPanelHeight - boardPadding * 2; final cellSize = min(availableWidth / cols, availableHeight / rows);

这里的关键是取min而不是max，这样保证棋盘在任何屏幕上都能完整显示，不会溢出。同时我在AspectRatio的约束下用GridView.builder渲染，配合NeverScrollableScrollPhysics禁用滚动，保证棋盘始终固定在一个可视区域内。数字字体大小也要根据格子大小动态调整，我使用cellSize * 0.5作为字体大小，测试下来在不同尺寸设备上基本都能保持数字在格子内的舒适比例。

我个人在做完这个项目后最大的体会是：数字显示是一个非常典型的前端问题，看起来简单，但真正做好需要从算法、状态、视觉、动画、适配多个层面去打磨。扫雷这款经典游戏之所以能穿越这么多年，很大程度归功于它把“数字信息”这种枯燥的东西用最直观、最省脑力的方式呈现给了玩家。当你在Flutter for OpenHarmony上把这个数字显示做到位，你会对这个框架在复杂状态和UI交织场景下的表现有了很深的把握，这个经验对后续做任何App模块都是有价值的。如果你也在尝试用Flutter做OpenHarmony游戏或者工具类应用，不妨先试一个扫雷模块，它真的是一个性价比极高的练手项目。