扫雷这个游戏估计没人没玩过。但用Java Swing亲手实现一个能玩、能赢、手感还顺滑的版本绝对比点开系统自带扫雷点掉一个下午有价值得多。我前段时间把完整的 javaswing实现扫雷游戏 从零写完从二维数组建模、布雷算法、递归展开到界面交互、事件监听、重绘优化一路踩了不少坑也把每个环节的原理摸得透透的。这篇就用实际项目复盘的方式把整体设计、核心算法、界面搭建、踩坑实录全部摊开来讲附带可以直接用的实现思路和关键代码。无论你是要做课程设计、巩固Java基础还是单纯想搞懂扫雷背后的逻辑这篇都值得收藏。1. 项目整体设计与思路拆解1.1 为什么选Swing而不是JavaFX或AWT很多第一次接触图形界面的同学选框架时会在Swing和JavaFX之间摇摆。我的结论很明确扫雷这个项目Swing是最合适的。依赖天然Swing是JDK自带的GUI工具包不需要引入任何第三方依赖环境配置成本几乎为零。JavaFX虽然界面更现代但需要额外安装模块Java 11之后还要单独配置对课设和入门项目来说反而增加了一大堆不必要的复杂度。事件模型匹配扫雷的核心交互是鼠标点击——左键开格、右键标旗、左右键同时按做和弦判定。Swing的MouseListener天然支持区分鼠标按键事件分发机制也很清晰非常适合这种高频点击交互的游戏。渲染足够用有人担心Swing重绘慢扫雷一个棋盘最多也就是30x30格每格一个按钮或者绘制区域用Swing的paintComponent完全扛得住。实测30x30的大师难度下一个格子都不卡。当然如果是做3D效果或者复杂动画那肯定要选JavaFX或游戏引擎。但扫雷这种2D网格类游戏Swing属于用起来舒服、调起来简单的最优选。1.2 扫雷核心逻辑的建模思路写扫雷第一步不是画界面而是想清楚数据模型。整个游戏本质上是在操作几个核心状态地雷分布用一个二维数组记录哪些格子有雷哪些没有。比如boolean[][] isMinetrue代表有雷。相邻雷数扫雷里每个数字格显示周围8个方向共几颗雷需要另一个二维数组int[][] hintNumber来存储。格子的状态每个格子当前是未翻开covered、已翻开revealed、被插旗flagged还是插错旗误标需要一个状态数组int[][] cellState。游戏状态进行中、胜利、失败用一个枚举或整型变量维护。剩余地雷数界面顶部通常显示剩余雷数这是可以动态递减的。这几个数据结构一旦想清楚整个项目的骨架就立住了。我见过很多同学一上来就先画界面画到一半发现逻辑不知道往哪塞最后强行把业务代码堆在事件监听器里一团乱麻。正确的顺序永远是先建模再实现逻辑最后做界面。1.3 游戏状态机的设计扫雷的流程不是线性的它是典型的“状态驱动”结构。我设计时用一个枚举来管理进度public enum GameState { RUNNING, // 游戏进行中 WIN, // 胜利 FAIL // 失败 }这里有一个很多人容易忽略的状态游戏刚开始还没有点到第一个格子的时候其实处于一个“预备”状态。很多实现把它和RUNNING合并但这样在首次点击布雷时还得单独判断是否已经布过雷。更好的做法是在按下第一个有效左键时才触发布雷逻辑并把状态从预备切到RUNNING。为了简洁很多代码里只用GameState就够了但你要清楚这只是状态管理的简化方案。另一个维度是格子的状态我用一个数组管理public static final int COVERED 0; // 未翻开 public static final int REVEALED 1; // 已翻开 public static final int FLAGGED 2; // 已标旗标旗和覆盖是两回事一定不能用同一个布尔量去表示。比如“已翻开”和“未翻开”用boolean但“插旗”需要单独存。常见错误是写了个isFlagged的布尔数组结果翻格子的逻辑判断if (!isFlagged)导致插了旗的格子也能被翻开。这种边界细节必须提前想清楚。2. 核心逻辑布雷、计算与扫雷规则2.1 随机布雷与“首点安全”实现布雷是整个游戏最基础的逻辑。乍一看很简单——随机生成雷的位置就行了但里面有一个必须处理的细节用户第一次点击的格子不能是雷否则游戏一开局就炸体验极差。常规做法有两种先把雷全部布好再检测首次点击位置是不是雷。如果是把雷移走或者重新生成。延迟布雷法在第一次点击之前不布任何雷等用户点下第一个格子后以这个格子为起点排除掉它本身以及周围8个格子在剩余区域布雷。第二种更优雅而且天然保证了“周边一圈安全”的入门体验。我也推荐按第二种来。具体逻辑public void layMines(int firstRow, int firstCol) { // 排除第一次点击的格子及其周围8格 boolean[][] block new boolean[rows][cols]; for (int dr -1; dr 1; dr) { for (int dc -1; dc 1; dc) { int nr firstRow dr, nc firstCol dc; if (inBounds(nr, nc)) block[nr][nc] true; } } int mineCount totalMines; Random rand new Random(); while (mineCount 0) { int r rand.nextInt(rows); int c rand.nextInt(cols); if (!isMine[r][c] !block[r][c]) { isMine[r][c] true; mineCount--; } } }雷数取多少经典扫雷有三个难度初级 9x9 共10雷中级 16x16 共40雷高级 16x30 共99雷。这些参数是Windows扫雷验证过的最佳配比直接抄就行。想进阶一点可以在设置面板中让玩家自定义行列数和雷数但雷的数量一般不超过格子总数的1/3否则开局死局率太高。2.2 周围雷数计算的两种方案布雷完成后下一步就是计算每个格子周围8格的雷数。这个计算有两条路方案A遍历每个非雷格扫描它周围8格数有多少个是雷。每个格子要查8次总时间复杂度 O(rows * cols * 8)实现直观逻辑不易出错。方案B遍历每颗雷对它周围的8个非雷格子执行“1”操作。这个时间复杂度同样是 O(mines * 8)但通常雷的数量远小于格子数所以实际运行更快。方案B是我推荐的因为它利用了“雷少”这一前提。演示一下public void calculateHints() { hint new int[rows][cols]; int[] dr {-1, -1, -1, 0, 0, 1, 1, 1}; int[] dc {-1, 0, 1, -1, 1, -1, 0, 1}; for (int r 0; r rows; r) { for (int c 0; c cols; c) { if (!isMine[r][c]) continue; for (int k 0; k 8; k) { int nr r dr[k], nc c dc[k]; if (inBounds(nr, nc) !isMine[nr][nc]) { hint[nr][nc]; } } } } }这段代码里出现了一个铁律雷的格子上的hint值永远不计算。因为游戏里你永远不应该看到雷格上的数字即使看到也是用图标覆盖所以存什么都无所谓但不计算可以防止调试时混淆。2.3 递归展开空白区域扫雷最爽的时刻是什么点开一个空格啪的一下连片展开大半个棋盘。这个效果的核心算法叫“泛洪填充”Flood Fill也叫洪泛展开。逻辑一句话解释如果当前格子不是雷且周边雷数为0则递归地翻开它周围8个格子遇到数字格或插旗格就停下来。public void reveal(int r, int c) { if (!inBounds(r, c) || state[r][c] REVEALED || state[r][c] FLAGGED) { return; } state[r][c] REVEALED; if (hint[r][c] 0) { for (int k 0; k 8; k) { reveal(r dr[k], c dc[k]); } } }这个递归看起来简单但有个隐形陷阱它没检查isMine。如果用户点到的是雷这个函数会被前面的逻辑挡住。我的习惯是把“点开雷则爆炸”的判断放在调用方reveal方法本身只负责展开不去管爆炸分支这样职责更清晰。另一个需要优化的问题是递归深度。30x30的地图在最坏情况下递归深度可能达到900层Java默认栈足够处理不会爆。但如果你把递归改成BFS广度优先或者用显式栈的迭代方式就更稳了。初版用递归完全OK进阶再优化。2.4 胜利与失败判定失败判定当用户点开的格子isMine为真游戏直接结束把所有雷显示出来。胜利判定扫雷的胜利条件不是“把雷全部标出来”而是翻开所有非雷格子。同样一个格子不标旗但被数字排除推理出它是雷也就等于玩家已经识别了它。所以判断逻辑是public boolean checkWin() { int revealedCount 0; int safeCount rows * cols - totalMines; for (int r 0; r rows; r) { for (int c 0; c cols; c) { if (state[r][c] REVEALED) revealedCount; } } return revealedCount safeCount; }这里有个小技巧每次翻开格子时维护一个revealedCount计数器就不用每次全盘扫描。性能看起来差距不大但30x30棋盘配合高频点击时每次都做矩阵遍历会有明显卡顿维护计数器才是正确姿势。实战中最容易犯的错误是把“插旗数量 总雷数”当成胜利条件。这样会造成一个哭笑不得的结果——玩家在不能确定雷的情况下乱标旗子硬标够了数量就赢了完全失去了推理的意义。所以一定要用“非雷格全部被翻开”作为唯一标准。3. Swing界面搭建与交互实现3.1 界面组件选型与布局设计界面结构我采用的是经典的上下面板分离顶部信息栏用JPanel承载剩余雷数标签、笑脸重开按钮、计时标签。用BorderLayout或FlowLayout都行重点是让三个信息元素横向排列紧凑。中央棋盘用JPanel配合GridLayout根据行列数动态设定。每一格可以用JButton来做也可以用自定义paintComponent绘制。我用的是前者因为JButton天然有按下、悬停的状态反馈写起来快不太依赖gif资源。棋盘面板的代码大致如下JPanel boardPanel new JPanel(); boardPanel.setLayout(new GridLayout(rows, cols)); for (int r 0; r rows; r) { for (int c 0; c cols; c) { JButton btn new JButton(); btn.setMargin(new Insets(0, 0, 0, 0)); btn.setFocusPainted(false); // 关联行列坐标 btn.putClientProperty(row, r); btn.putClientProperty(col, c); boardPanel.add(btn); } } mainFrame.add(boardPanel, BorderLayout.CENTER);特别注意putClientProperty存坐标这个技巧它让事件监听器能拿到按钮对应的行列不用手动维护“按钮-格子”的Map。比在按钮实例类里存row/col字段更素雅也方便多个面板复用。3.2 鼠标事件监听左键、右键与和弦判定扫雷鼠标交互有三类左键单击翻开格子。右键单击标记或取消标记旗帜。左右键同时按经典扫雷里的“和弦”chord功能——如果一个已翻开的数字格周围旗子数量等于数字左右键同时按下会将其余未旗子格子全部翻开。Swing里区分左右键非常简单在MouseListener.mouseClicked里用SwingUtilities.isLeftMouseButton/MiddleMouseButton判断。但左右键同时按的情况并不总能触发mouseClicked稳妥的做法是监听mousePressed和mouseReleased分别记录左右键按下的状态再用一个状态机判断boolean leftPressed false, rightPressed false; public void mousePressed(MouseEvent e) { if (SwingUtilities.isLeftMouseButton(e)) leftPressed true; if (SwingUtilities.isRightMouseButton(e)) rightPressed true; if (leftPressed rightPressed cellState REVEALED) { // 执行和弦逻辑 chordAction(row, col); } } public void mouseReleased(MouseEvent e) { if (SwingUtilities.isLeftMouseButton(e)) leftPressed false; if (SwingUtilities.isRightMouseButton(e)) rightPressed false; }这个逻辑看起来平平无奇但有一个重要的前提只有已经翻开的数字格才响应和弦。新手经常把和弦判断放在所有格子结果在未翻开的格子上左右键同时按也触发逻辑导致界面混乱。3.3 面板刷新策略与性能调优Swing是单线程的所有UI操作必须运行在事件分发线程EDT上。因此所有逻辑处理完之后统一调用boardPanel.repaint()来触发重绘就行。这里有个性能细节千万不要在循环里频繁调用repaint比如在递归展开里每翻开一格就repaint一次那样会导致界面大量重绘肉眼可见地卡顿。正确做法是全部状态更新到位后一次性repaint// 递归展开期间只修改state数组 reveal(r, c); // 等递归全部结束后统一刷新 boardPanel.repaint();实测下来30x30棋盘一次重绘耗时在十几毫秒内即便连续快速点击多个格子UI依然顺滑。如果发现重绘有残影或闪烁可以重写JPanel的paintComponent时开启双缓冲Swing默认已经开了一般不用额外设置。如果你是使用JButton实现的格子那么你会发现 JButton 的更新需要逐个 setIcon 或者 setBackground。这里的性能瓶颈不在于重绘而在于你在递归展开里对几百个按钮逐个调用setter方法比较耗时。我当时为了方便用JButton在初级难度下没问题但高级难度连续翻出大片空白时能感觉到轻微迟滞后来果断换成自定义绘图方式才彻底解决。3.4 计时器与剩余雷数显示计时功能用javax.swing.Timer实现最方便不会像Thread.sleep那样阻塞事件线程。核心逻辑是每秒触发一次ActionEvent更新计时标签Timer timer new Timer(1000, e - { elapsedSeconds; timeLabel.setText(String.format(%03d, elapsedSeconds)); });要注意的是游戏开始计时的时间节点是第一次有效左键点击不是窗口打开的时候。这也和延迟布雷逻辑配合——第一次点击同时触发布雷和启动计时器。雷数显示则是totalMines - flaggedCount维护一个整数变量每次标旗或取消标旗时更新即可。还有个小技巧把计时器的start和stop和游戏状态机绑定起来。游戏处于预备状态时计时器不启动失败/胜利时stop。否则会出现游戏已经输了计时还在跑的笑话。4. 完整实操过程与核心代码实现4.1 类结构设计我建议一个完整项目拆成下面几个类避免单文件过大MinesweeperModel负责数据建模、布雷、hint计算、翻开/标旗/和弦逻辑、胜利判断。GamePanel继承JPanel负责绘制棋盘界面接收鼠标事件调用Model更新数据再重绘。InfoPanel顶部信息栏雷数、笑脸按钮、计时器。MainFrame主窗口用BorderLayout组合InfoPanel和GamePanel。Model和View分离的好处是如果后续想加“自动解谜”AI只需要写一个算法类去操作Model的方法完全不用碰界面代码。这在课程设计的答辩加分环节特别有用。4.2 界面绘制JButton还是自定义绘图我上面提到换成了自定义绘图这是扫雷项目从初中级进阶到一个档次的标志性改动。自定义绘图的思路是GamePanel内部维护一个二维格子数组每格去识别state单元格的状态并用Graphics画出对应内容。Override protected void paintComponent(Graphics g) { super.paintComponent(g); for (int r 0; r rows; r) { for (int c 0; c cols; c) { int x c * cellSize, y r * cellSize; drawCell(g, r, c, x, y); } } }drawCell里根据状态和hint值绘制不同图案覆盖时绘制灰色凸起边框。插旗时在灰色底上绘制小红旗。翻开时绘制浅色底数字用不同颜色1蓝色、2绿色、3红色、4深蓝、5深红、6青色、7黑色、8灰色。展示雷时绘制黑色地雷图案。自定义绘图比较考验耐心但换来的是流畅的交互体验和对Swing绘制机制更深入的理解。这里我给两个核心技巧第一数字颜色可以定义为静态数组Color[] numberColors {..., Color.BLUE, new Color(0, 128, 0), ...}然后g.setColor(numberColors[hintValue])方便维护。第二凸起边框效果可以用g.draw3DRect实现传入true表示凸起翻开后传入false表示凹陷视觉效果和原版扫雷几乎一样。4.3 核心交互流程的实现细节我把鼠标处理拆成了两个方法handleLeftClick(row, col)和handleRightClick(row, col)思路更清晰。左键处理的完整流程如下public void handleLeftClick(int r, int c) { if (gameOver || state[r][c] REVEALED || state[r][c] FLAGGED) return; if (firstClick) { layMines(r, c); calculateHints(); firstClick false; timer.start(); } if (isMine[r][c]) { // 游戏失败 gameOver true; gameState GameState.FAIL; revealAllMines(); timer.stop(); // 显示失败表情 } else { reveal(r, c); if (checkWin()) { gameOver true; gameState GameState.WIN; timer.stop(); // 自动给剩余雷插旗显示胜利表情 } } repaint(); }这段代码把“第一次点击布雷”、“踩雷失败”、“翻开”、“胜利判定”四个分支全部集中在一个方法里逻辑顺序一目了然。右键处理就简单多了只做插旗与取消插旗同时检查该格是否已经翻开。4.4 键盘与无障碍细节很多人忽略键盘支持但加上了能明显提升作品完成度。我实现了几个快捷键空格键模拟左键翻开当前聚焦格子F键模拟插旗。在JPanel上设置Focusable重写keyPressed即可。不过要提醒一下Swing默认的JButton会抢焦点如果你是纯按钮方案空格键可能和按钮自身的激活逻辑冲突。自定义绘图方案没有这个烦恼。4.5 进阶功能扩展难度切换、排行榜与动画难度切换在菜单栏或面板上加三个单选框选择后重建Model和GamePanel重置计时器。行列和雷数可以自定义。排行榜胜利时记录用时存入本地文件Properties或序列化对象都行。这个玩法在课设答辩中很拉好感。雷区动画失败时雷爆炸然后逐渐变成红色背景或者用简单的缩放绘制实现。Swing动画可以借助javax.swing.Timer周期性改变状态并调用repaint每次修改一个帧计数变量就可以。我当时做了一版“失败后雷开始闪烁”的效果用Timer驱动效果很炫但注意不能让定时器泄露——游戏结束时释放掉否则玩家再次开局后会出现多个动画引擎同时运行导致性能问题。5. 常见问题与排查技巧实录5.1 图标和图片加载不出来的经典坑不少人喜欢在JButton上用ImageIcon显示旗子和雷写代码时直接用相对路径src/images/flag.png结果打包运行后就找不到图片。这里有两个解决方案把图片放进resources目录用getResourceAsStream加载。更稳妥的做法是完全不用外部图片遇到旗帜、雷这些图案直接用Graphics绘制也就是我前面说的自定义绘图方案。这样不但免去资源路径的坑也让整个程序更轻量。如果你就想用ImageIcon记住一点不要用文件路径要用类路径new ImageIcon(App.class.getResource(/images/flag.png));5.2 递归展开遇到大棋盘就卡顿甚至卡死我之前说过用递归展开可能有性能隐患。但卡死还可能因为不是递归本身而是展开了“不该展开的格子”。比如你的递归出口没有把已经翻开的格子挡住导致A翻开B、B翻开A的无限循环。这就是死递归栈越用越深最终StackOverflow。排查方法也很简单在递归的第一行打印r, c或者用System.out输出翻开顺序一眼就能看出来哪里在反复横跳。平时规范起见始终在reveal方法开头检查state状态已经是REVEALED或FLAGGED就直接return别给死循环留空间。5.3 左右键同时按下时偶尔没反应这个问题是事件顺序造成的。在某些系统上左右键快速同时按下时系统可能只派发了一个按键的mousePressed另一个事件丢失或延迟。解决办法是把和弦逻辑放到mouseReleased里进行判断并且同时检查两个按键的按下状态public void mouseReleased(MouseEvent e) { if (leftPressed rightPressed SwingUtilities.isLeftMouseButton(e)) { doChord(); } // 更新按键状态 }应用层建议不要依赖“完美的同时”而是在任意一个按键释放时如果另一个按键还处于按下状态就执行和弦逻辑。这样用起来更跟手不容易漏判。5.4 界面缩放后布局错乱有人把主窗口设置成setSize(400, 500)后直接使用绝对定位最后发现分辨率一变界面就乱成一团。我的建议是全部使用布局管理器要让 GridLayout 和 BorderLayout 去处理格子尺寸变化。棋盘格子的大小用 Math.min(panel.getWidth()/cols, panel.getHeight()/rows) 动态计算重绘时重新取。另一个坑是底部的信息面板用FlowLayout窗口变宽后左右元素分散得很开看起来就不紧凑。改成固定宽度或者用BoxLayout纵向排列会好看很多。最终极的解决方案是禁止用户随意缩放窗口大小——直接setResizable(false)对扫雷这种固定棋盘的游戏非常合理。5.5 计时器泄漏开局后上次的计时器还在跑这个问题很隐蔽。如果你用javax.swing.Timer并且没有在重建棋盘时stop旧的Timer那旧Timer会继续触发监听器更新一个已经不在界面上显示的标签导致新游戏计时不但被干扰有时还会每秒跳两下。经典表现新游戏开局后计时数字自己每秒2甚至跳得飞快。排查方法在重建GamePanel时务必确保Timer已经停止并移除旧Timer绑定的ActionListener。最佳实践是让Timer只归InfoPanel管重建棋盘时只重置TimeLabel的文本而不是新new一个Timer。这样从源头避免了泄漏问题。5.6 标旗数量与剩余雷数不对应很多人把剩余雷数显示为totalMines - flaggedCount但玩家可以标记任意多个旗子比如雷还没找到10颗就顺手标了20面旗剩余雷数变成负的。这不算bug但显示成负数很难看。合理的做法是允许负数显示经典扫雷也是这么表现的或者只显示成0。个人建议保持负数因为它能直观提醒玩家你已经标错了得多想想再标旗。6. 实操心得与经验补充6.1 我踩过的最有价值的坑第一版我用纯JButton实现写起来很爽但到了高级难度棋盘上几百个按钮组件堆在一起初始化耗时明显。后来全部换成自定义绘图体验好了很多也让我真正理解到Swing的绘制机制不是为十几万个组件设计的。如果你的目标是做一个“能流畅跑高级难度”的扫雷自定义绘图是必由之路。第二层体会是关于事件处理的。我把和弦逻辑绑在mousePressed上结果在很多鼠标上它根本不触发。后来改成上面说的“释放时判断双键状态”才真正稳定下来。这是常规书籍不会讲的细节得靠实际使用各种鼠标才能体会到。6.2 怎么让作品在课设中脱颖而出如果只是想及格写个能玩的扫雷就够了。但想拿高分建议考虑这几个加分项自定义难度允许输入任意行列数和雷数。排雷器/自动标记在一个已翻开的数字格上如果周围旗子数量等于数字单击自动翻开其他格子。重开按钮的形象反馈迷之时、踩雷时、胜利时笑脸按钮分别显示不同表情。存档与排行榜用文件保存最佳时间和胜率。双模式切换经典模式与“无雷模式”纯推理不涉及踩雷后者特别适合锻炼逻辑。6.3 关于代码注释和结构的执念我强烈建议把Model和View分离哪怕只是个课设。不是因为“设计模式听起来高级”而是当你需要排查一个雷数计算的bug时你会感激自己当初把业务逻辑写成了纯Java类而不是散落在监听器里的几百行泥团。我当时写的时候养成的习惯是Model内所有改变状态的方法都返回void由View在调用后统一repaint逻辑非常集中很好debug。最后说个心态层面的小建议扫雷这种经典小游戏代码量不大逻辑也不复杂但它是为数不多需要真正调通“鼠标交互TIMER递归状态管理”的练手项目。把这几块吃透以后做任何Swing或Android界面项目底子都稳得多。如果你正在做这个项目把上面的关键点记下来真的能少踩很多坑。
