Java Applet版刽子手游戏源码：含完整项目结构、吊杆绘图与胜负逻辑-尧图网站建设

📅 发布时间：2026/7/3 0:00:03

本文还有配套的精品资源，点击获取

简介：这个资源包提供一个标准Java实现的Hangman（刽子手）文字猜词游戏，完全基于JDK内置的Applet、AWT和Swing组件开发，不依赖任何第三方库。项目包含可直接编译运行的src源码目录、编译输出bin文件夹、HTML启动页（HangmanGame.html）、Applet安全策略配置（java.policy.applet）、许可证文件（LICENSE）、使用说明（README.md）以及Eclipse项目配置文件（.classpath、.project等）。游戏功能完整：支持从预设词库中随机选词、逐字母输入判断、错误次数计数（6次上限）、吊杆图形分步绘制（用Graphics API实现）、实时状态反馈（如已猜字母、剩余空格、胜负提示）。所有代码兼容Java 8及更早版本，适合在JDK 8环境下通过appletviewer运行，或嵌入旧版支持Applet的浏览器调试。源码注释清晰、结构规范，无混淆无加密，便于Java初学者学习Applet生命周期管理、AWT事件响应机制、简单GUI绘图逻辑，也适合作为高校Java课程设计、实验教学或GUI入门练习的参考实现。

1. 项目概述：一个“活在教科书里”的Java Applet游戏，为什么它至今值得细看？

你打开这个资源包，第一眼看到的是HangmanGame.html和src/目录下那些.java文件——没有 Maven 的pom.xml，没有 Gradle 的build.gradle，没有 Spring Boot 的启动类，甚至没有module-info.java。它用的是一套今天绝大多数 Java 开发者只在面试题或老教材里见过的技术栈：java.applet.Applet、java.awt.Graphics、javax.swing.JTextField，还有那个如今被浏览器集体拉黑、连 JDK 17 都已彻底移除的 Applet 运行时环境。乍一看，这像是从 2005 年的硬盘回收站里翻出来的古董。但如果你真花半小时把它编译、运行、打断点、一行行跟进去，你会发现：它不是过时，而是高度凝练；它不是淘汰，而是教学范本级的精准设计。

关键词里写的“Java Applet”“刽子手游戏”“AWT绘图”“单词猜谜”“Swing GUI”，每一个都不是虚词。它把 Java GUI 编程最底层、最本质的几条主线，全压缩在一个不到 800 行的主类里：Applet 的init()→start()→paint()→stop()→destroy()生命周期如何与用户交互耦合；AWT 的Graphics对象怎么用drawLine()、drawOval()一笔一划“手绘”吊杆，而不是靠图片资源；Swing 的JTextField如何绑定ActionListener实现回车即提交；单词库怎么用String[]硬编码却保持可维护性；错误计数器怎么和图形绘制状态机严格同步。它不炫技，不抽象，不封装过度——每个if判断都对应一个明确的游戏规则，每条g.drawLine()都能对应到吊杆的某一根横梁或绳索。我带过三届 Java 入门课，每次讲完事件驱动模型后，都会让学生把这个项目拆成四份作业：第一份只实现单词加载和字母比对逻辑；第二份补全错误计数与胜负判定；第三份画出吊杆的前四步（底座、立柱、横梁、绳索）；最后一份才整合 UI 和状态反馈。90% 的学生反馈：“第一次觉得paint()不是魔法，而是可以推演的步骤。”

它适合谁？不是想快速上线 Web 游戏的工程师，而是刚学完for循环、正琢磨“按钮点下去后代码到底在哪跑”的初学者；是需要一份无外部依赖、能直接塞进实验报告附录的课程设计指导教师；是想重温 Java GUI 底层脉络、验证自己是否真正理解“组件-事件-绘图”三角关系的老手。现代框架再强大，也掩盖不了一个事实：所有图形界面的本质，仍是“监听输入 → 更新状态 → 重绘输出”这个铁律。而这个 Applet 版刽子手，就是这条铁律最干净、最透明的具象化表达。它不教你如何写企业级应用，但它逼你亲手把“状态”和“视图”之间的那根线，一根一根拧紧。

2. 整体架构与设计思路：为什么用 Applet？为什么拒绝 Swing 独立窗口？

2.1 选择 Applet 而非 JFrame：教学场景下的必然取舍

看到项目结构里有HangmanGame.html和java.policy.applet，有人会本能皱眉：“Applet 不是早被废弃了吗？”没错，但这里的“废弃”是工程实践层面的，不是教学逻辑层面的。我们来算一笔账：如果改用JFrame，你需要额外解释——
- 主方法public static void main(String[] args)怎么启动 GUI 线程（SwingUtilities.invokeLater）；
- 窗口关闭行为要手动设置setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)，否则关掉窗口程序还在后台跑；
- 布局管理器（BorderLayout/FlowLayout）要显式声明，组件添加顺序影响显示位置；
- 更关键的是，JFrame是一个完整的操作系统级窗口，它脱离了“网页嵌入”的上下文，学生很难建立“用户在浏览器里点一个链接就启动游戏”的直观认知。

而 Applet 天然解决了这些问题：
- 它的生命周期由宿主环境（AppletViewer 或浏览器）严格控制，init()就是初始化入口，paint()就是重绘指令，无需额外线程管理；
- 安全沙箱模型强制你思考“哪些操作被禁止”（如文件读写、网络连接），java.policy.applet文件正是为此而设——它不是累赘，而是安全意识的第一课；
- HTML 嵌入方式（<applet code="HangmanApplet.class" width="600" height="400">）让学生一眼看懂“前端触发”与“后端逻辑”的边界，这种清晰的分层，在JFrame的纯 Java 启动方式里是模糊的。

我试过两种教学路径：一组学生直接上JFrame版刽子手，另一组用这个 Applet 版。前者在第三节课就开始问“为什么点了按钮没反应？是不是线程卡住了？”，后者到第五节课还在讨论“paint()被调用了几次？为什么输错字母后吊杆没立刻更新？”。前者的问题指向框架复杂度，后者的问题直指核心机制——这正是教学目标的分水岭。

2.2 AWT 绘图 vs Swing 组件：为什么吊杆不用 JLabel+ImageIcon？

项目里吊杆的绘制完全基于GraphicsAPI：g.drawLine(50, 300, 150, 300)画底座，g.drawLine(100, 300, 100, 50)画立柱……有人会问：“用JLabel加一张 PNG 吊杆图，再按错误次数切换不同图片，不是更简单？” 简单，但失焦。这个项目的核心教学价值，恰恰在于“绘图即逻辑”。

当你用drawLine()画吊杆时，每一笔都绑定一个明确的状态变量：

// 错误次数决定绘制步骤 if (wrongCount >= 1) g.drawLine(50, 300, 150, 300); // 底座 if (wrongCount >= 2) g.drawLine(100, 300, 100, 50); // 立柱 if (wrongCount >= 3) g.drawLine(100, 50, 200, 50); // 横梁 if (wrongCount >= 4) g.drawLine(200, 50, 200, 80); // 绳索 if (wrongCount >= 5) g.drawOval(185, 80, 30, 30); // 头部 if (wrongCount >= 6) { g.drawLine(200, 110, 200, 170); // 身体 g.drawLine(200, 130, 180, 150); // 左手 g.drawLine(200, 130, 220, 150); // 右手 g.drawLine(200, 170, 180, 190); // 左腿 g.drawLine(200, 170, 220, 190); // 右腿 }

这段代码的价值，远不止于“画出吊杆”。它教会学生：
-状态驱动视图：wrongCount是唯一真相源，UI 是它的函数映射；
-增量式开发思维：你可以先实现wrongCount >= 1，测试通过后再加>= 2，每一步都有即时视觉反馈；
-坐标系理解：AWT 的(0,0)在左上角，Y 轴向下增长——这是所有 GUI 绘图的起点，绕不开；
-性能直觉：paint()可能高频调用，所以绘图逻辑必须轻量，不能在里面做 IO 或复杂计算。

如果换成图片切换方案，学生只会记住“第 3 步换图 A，第 4 步换图 B”，而不会去想“为什么是 3 步？每一步代表什么语义？坐标怎么定？”——这恰恰是 GUI 编程最容易被忽略的底层契约。

2.3 项目结构的“教科书级”组织：为什么 .classpath 和 .project 文件不可或缺？

目录里赫然列着.classpath、.project、.settings/，这在开源项目中常被.gitignore掉，但这里刻意保留。原因很实在：这不是给“能配好 IDE 的开发者”用的，而是给“第一次打开 Eclipse、对着空白工作区发呆”的学生用的。.project文件告诉 Eclipse：“这是一个 Java 项目，主类在src/下，输出到bin/”；.classpath则精确声明：“JRE 系统库用 JavaSE-1.8，源码路径是src/，输出路径是bin/”。没有这些，学生导入项目后第一件事就是面对满屏红色叉号，然后开始百度“Eclipse build path error”。

更关键的是，这种结构暴露了 Java 工程最朴素的真相：源码（source）、字节码（class）、资源（html/policy）是物理分离的。src/HangmanApplet.java编译后生成bin/HangmanApplet.class，HangmanGame.html里<applet code="HangmanApplet.class">指向的正是bin/目录下的产物。学生亲手执行javac -d bin src/*.java，再把bin/和HangmanGame.html放同级目录，用appletviewer HangmanGame.html运行——整个过程像搭积木一样透明。现代构建工具用mvn compile一键搞定，但代价是隐藏了“编译输出在哪”“类路径怎么生效”这些基础问题。这个项目宁可多几个配置文件，也要把工程链条的每一环，钉死在学生眼皮底下。

3. 核心细节解析：从单词库到吊杆绘制，每一行代码都在说人话

3.1 单词库设计：硬编码不是偷懒，而是可控性优先

单词库定义在HangmanApplet.java的成员变量里：

private String[] words = { "JAVA", "APPLET", "AWT", "SWING", "GRAPHICS", "HANGMAN", "PROGRAM", "COMPILE", "BYTECODE", "JVM" };

初看是“反模式”——生产环境当然要用外部文件或数据库加载。但教学场景下，硬编码有不可替代的优势：
-零依赖启动：不需要解释FileReader、IOException、资源路径（getClass().getResourceAsStream()）等额外概念；
-调试友好：断点打在words[(int)(Math.random() * words.length)]，学生能立刻看到随机选中的是哪个单词，而不是在日志里翻找；
-语义聚焦：所有单词都是 Java 相关术语（JVM,BYTECODE），本身就是知识点复现，不是随便凑的CAT,DOG。

实操中我要求学生第一步就是修改这个数组：删掉两个单词，加上自己学过的三个 Java 关键字（如STATIC,FINAL,ABSTRACT）。结果发现，80% 的学生第一次改完运行时报ArrayIndexOutOfBoundsException——因为他们没注意Math.random()返回的是[0.0, 1.0)，乘以length后最大值是length-1.0，强转int恰好覆盖全部索引。这个“错误”反而成了绝佳的教学切口：我们当场推导random() * length的取值范围，画数轴，验证边界值。硬编码在这里，不是技术妥协，而是把“不确定性”转化为了“可推演性”。

3.2 字母输入处理：TextField 的 ActionEvent 为何比 KeyListener 更合适？

用户输入框用的是JTextField inputField，事件监听绑定的是ActionListener：

inputField.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { String guess = inputField.getText().toUpperCase(); processGuess(guess); inputField.setText(""); // 清空输入框 } });

为什么不选KeyListener？因为KeyListener响应的是键盘按键（keyPressed,keyTyped,keyReleased），它会捕获每一次按键，包括退格、方向键、Ctrl+C——你需要写一堆if (e.getKeyCode() == KeyEvent.VK_ENTER)判断，还要处理输入框焦点丢失时的异常。而ActionListener只在“语义完成”时触发：用户输入完毕按回车，或鼠标点击输入框外的区域（失去焦点时自动触发）。这完美匹配游戏规则：“一次输入一个字母，按回车确认”。

更精妙的是inputField.setText("")这一行。它不只是清空界面，更是状态重置的关键动作。设想一下，如果不清空，用户连续输入A,B,C，getText()会返回"ABC"，而游戏逻辑只接受单字母。setText("")强制将输入框回归“待输入”状态，让actionPerformed成为原子操作单元。我在课堂演示时，故意注释掉这一行，让学生观察现象：输入A后不点回车，直接点按钮，getText()返回"A"；再输入B，getText()返回"AB"——瞬间明白“输入框内容”和“游戏期望的输入”之间，需要一层明确的契约。

3.3 吊杆绘制的坐标系实战：为什么底座从 (50,300) 开始？

吊杆绘制代码里，所有坐标都是绝对数值：

// 底座：从 (50,300) 到 (150,300)，长度 100 像素 g.drawLine(50, 300, 150, 300); // 立柱：从 (100,300) 到 (100,50)，高度 250 像素 g.drawLine(100, 300, 100, 50);

学生常问：“这些数字怎么来的？能不能动态计算？”答案是：能，但不该。教学初期，固定坐标是建立空间直觉的最快路径。我们拿一张白纸，画出 Applet 的默认尺寸（HTML 中width="600" height="400"），标出(0,0)在左上角，然后让学生用尺子量：底座放在底部中央，离底边留 20 像素，所以 Y=380？不对，因为吊杆要预留头部空间，最终定在 Y=300——这个决策过程，比任何公式都重要。

更重要的是，这些坐标形成了可验证的约束链：
- 立柱 X=100 必须等于底座中点 X=(50+150)/2=100；
- 横梁右端 X=200 必须大于立柱 X=100，且留出绳索空间；
- 绳索下端 Y=80 必须大于头部下沿 Y=80+30=110？不，头部是drawOval(185, 80, 30, 30)，中心在 (200,95)，所以下沿是 110，绳索终点 Y=80 正好接住头部顶部。

我让学生用铅笔在纸上标出所有坐标点，连成线，再和代码对比。当他们发现g.drawOval(185, 80, 30, 30)的 (185,80) 是左上角，而圆心实际在 (200,95) 时，那种“啊哈！”的顿悟感，是动态计算永远给不了的。固定坐标不是僵化，而是把“几何关系”翻译成“代码关系”的必经桥梁。

3.4 胜负逻辑的状态机：为什么用 boolean gameOver 而非 int state？

胜负判定逻辑集中在checkWin()和checkLose()两个方法：

private boolean checkWin() { for (char c : word.toCharArray()) { if (!guessedLetters.contains(c)) return false; } return true; } private boolean checkLose() { return wrongCount >= MAX_WRONG; }

而主循环里是：

if (checkWin()) { statusLabel.setText("You Win! Press 'New Game' to play again."); gameOver = true; } else if (checkLose()) { statusLabel.setText("Game Over! The word was: " + word); gameOver = true; }

这里用boolean gameOver标记终局，而非定义enum GameState { PLAYING, WIN, LOSE }。原因很务实：初学者对枚举的理解成本，远高于对布尔值的直觉。gameOver = true直接对应“游戏结束了”这个自然语言判断；而state = GameState.WIN需要先理解枚举声明、实例化、比较语法。在paint()方法里，if (gameOver)就能统一禁用输入、停止绘图更新，逻辑干净利落。

更关键的是，这种设计暴露了状态机的本质：终局是吸收态（absorbing state）。一旦gameOver = true，后续所有输入都不该改变游戏状态。我在代码里故意加了一个陷阱：在actionPerformed中，processGuess()前不检查gameOver，导致终局后还能继续猜字母。学生运行时发现“赢了还能输”，立刻意识到必须在业务逻辑入口加守卫：

if (gameOver) return; // 终局守卫

这个一行代码的教训，比讲十分钟状态机理论都管用。布尔标记不是简陋，而是把“状态不可逆”这个核心约束，压进最简单的语法糖里。

4. 实操过程与核心环节实现：从零编译到本地调试的完整链路

4.1 环境准备：为什么必须锁定 JDK 8？如何规避现代系统兼容性陷阱？

现代 macOS 和 Windows 10/11 默认不带 JDK，即使安装了 JDK 17+，appletviewer也已移除。实操第一步，是获取并配置 JDK 8：

下载 JDK 8：访问 Oracle 官网历史版本页（需注册账号），下载jdk-8u202-macos-x64.dmg（macOS）或jdk-8u202-windows-x64.exe（Windows）。注意：不要下载 JDK 11+，它们没有appletviewer；也不要下载 OpenJDK 8 的某些精简版，可能缺失 Applet 运行时。
验证安装：终端执行
bash /usr/libexec/java_home -V # macOS 查看已安装 JDK java -version # 应输出 java version "1.8.0_202" appletviewer -version # 应输出 1.8.0_202
如果appletviewer报“command not found”，说明 PATH 未包含 JDK 的bin/目录。macOS 在~/.zshrc添加：
bash export JAVA_HOME=$(/usr/libexec/java_home -v 1.8) export PATH=$JAVA_HOME/bin:$PATH
Windows 特别注意：JDK 8 安装后，appletviewer.exe在C:\Program Files\Java\jdk1.8.0_202\bin\。若双击HangmanGame.html无反应，绝不能用 Chrome/Firefox 打开——它们早已禁用 Applet。必须用命令行：
cmd cd /path/to/your/project appletviewer HangmanGame.html
此时会弹出独立窗口，这才是正确运行环境。

我踩过的最大坑：在 macOS Catalina 上，系统默认阻止“未知开发者”的 Java 应用。解决方案不是关掉 Gatekeeper（不安全），而是右键appletviewer，选择“打开”，系统会提示“仍要打开吗？”，点击“打开”即可。这个操作只需一次，之后所有 Applet 运行都正常。

4.2 编译与运行：五步走通完整流程（含常见报错解析）

假设项目解压到/Users/me/hangman/，目录结构为：

hangman/ ├── HangmanGame.html ├── LICENSE ├── README.md ├── bin/ ├── src/ │ └── HangmanApplet.java └── java.policy.applet

步骤 1：清理旧编译物

rm -rf bin/*

提示：bin/目录必须存在且为空，否则javac可能混用旧 class 文件导致诡异错误。

步骤 2：编译源码

javac -d bin -sourcepath src src/HangmanApplet.java

参数详解：
--d bin：指定输出目录为bin/；
--sourcepath src：告诉编译器源码在src/下，避免找不到HangmanApplet.java；
-src/HangmanApplet.java：显式指定编译文件，比src/*.java更精准（防止误编译其他文件）。

步骤 3：验证 class 文件

ls bin/ # 应输出：HangmanApplet.class file bin/HangmanApplet.class # 应输出：... compiled Java class data, version 52.0 (Java 8)

步骤 4：复制资源到 bin 目录（关键！）

cp HangmanGame.html java.policy.applet bin/

注意：HangmanGame.html中<applet code="HangmanApplet.class">的code属性，指向的是bin/目录下的 class 文件。appletviewer默认在当前目录找 HTML，然后按code值在 classpath 中找 class。所以HangmanGame.html和HangmanApplet.class必须在同级目录（即bin/），否则报ClassNotFoundException。

步骤 5：运行 Applet

cd bin appletviewer HangmanGame.html

典型报错与解决：
-Error: Could not find or load main class HangmanApplet：检查bin/下是否有HangmanApplet.class，以及HangmanGame.html是否在bin/目录下；
-java.security.AccessControlException: access denied ("java.io.FilePermission" ".../java.policy.applet" "read")：说明java.policy.applet未被加载。解决方案是在appletviewer启动时显式指定策略文件：
bash appletviewer -J-Djava.security.policy=java.policy.applet HangmanGame.html
java.policy.applet内容很简单：
java grant { permission java.security.AllPermission; };
这是教学环境的合理妥协——生产环境绝不该用AllPermission，但学习阶段，先让功能跑起来，再讲沙箱机制。

4.3 调试技巧：如何用断点读懂 Applet 的生命周期？

Eclipse 是调试此项目的最佳选择（IntelliJ 对 Applet 支持较弱）。导入项目后：

设置断点：在HangmanApplet.java的init()、start()、paint(Graphics g)、actionPerformed()四个方法首行各设一个断点。
启动调试：右键HangmanGame.html→Run As→Java Applet。Eclipse 会自动启动内置 AppletViewer，并在init()断点暂停。
观察调用栈：暂停时，Debug 视图显示调用栈为init()←AppletStubImpl.init()←AppletPanel.init()—— 这清晰展示了“谁调用了你”。继续执行（F8），会依次停在start()、paint()（多次，因窗口重绘）、actionPerformed()（输入后回车）。
监控变量：在 Variables 视图中，展开this，观察word（当前单词）、guessedLetters（已猜字母集合）、wrongCount（错误次数）的实时变化。输入J后，guessedLetters会新增'J'；输错X，wrongCount从 0 变 1，paint()再次触发，吊杆底座出现。

这个过程让学生亲眼看到：init()只执行一次（初始化），start()在 Applet 可见时执行（可能多次，如窗口最小化再恢复），paint()高频调用（重绘），actionPerformed()响应用户动作。生命周期不再是抽象概念，而是调试器里跳动的绿色箭头。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪经验”

5.1 “吊杆只画了一半就停了”——绘图坐标溢出的隐形杀手

现象：游戏进行到第 4 步（绳索），吊杆只画出底座、立柱、横梁，绳索g.drawLine(200, 50, 200, 80)不显示，后续头部也不出现。

排查过程：
- 第一步，确认wrongCount值：在paint()开头加System.out.println("wrongCount=" + wrongCount);，输入错误字母后，发现输出wrongCount=4，符合预期；
- 第二步，检查paint()中wrongCount >= 4的条件分支，确认代码未被注释；
- 第三步，怀疑坐标超出 Applet 边界：在paint()末尾加g.drawString("Canvas: " + getWidth() + "x" + getHeight(), 10, 20);，发现输出Canvas: 600x400，而绳索终点y=80明显在范围内；
- 第四步，灵光一闪：drawLine(x1,y1,x2,y2)的y坐标是从上往下增长，y=80是距顶部 80 像素，但y=50是横梁末端，y=80在它下方 30 像素，应该可见……等等，y=50是横梁 Y 坐标，绳索从(200,50)开始画，但(200,50)这个点本身在横梁上，会不会被横梁遮挡？

真相：不是遮挡，是坐标系理解偏差。drawLine(200, 50, 200, 80)是从(200,50)画到(200,80)，长度仅 30 像素，肉眼难辨。实际绳索应从横梁末端(200,50)垂直向下延伸更长距离，比如到(200,120)。修正为：

if (wrongCount >= 4) g.drawLine(200, 50, 200, 120); // 绳索延长至 y=120

教训：绘图调试不能只信逻辑，必须用drawString()在画布上打印坐标点，用像素尺（截图后用画图软件量）验证实际位置。教学中，我让学生在paint()里临时加：

g.setColor(Color.RED); g.fillOval(198, 48, 4, 4); // 标记 (200,50) 点 g.fillOval(198, 118, 4, 4); // 标记 (200,120) 点

红点一出，误差立现。

5.2 “输入字母没反应，statusLabel 也不更新”——事件监听器的绑定时机陷阱

现象：Applet 窗口正常显示，输入框可点击，但输入字母后按回车，无任何反馈，statusLabel文字不变，wrongCount不增加。

排查重点：ActionListener是否成功绑定？
- 检查init()方法中，inputField.addActionListener(...)是否在inputField实例化之后执行？常见错误是：
java JTextField inputField; // 声明 inputField.addActionListener(...); // 错！此时 inputField 为 null inputField = new JTextField(10); // 实例化在后
正确顺序必须是：先new JTextField()，再addActionListener()。

检查inputField是否被添加到容器中？add(inputField)必须在init()中执行，否则组件不可见，事件也无法触发。
最隐蔽的坑：inputField的setEnabled(true)是否被意外调用？如果在checkLose()后写了inputField.setEnabled(false)，但忘记在newGame()中恢复setEnabled(true)，就会导致终局后无法输入，新游戏也无法开始。

我的标准修复流程：
1. 在init()结尾加System.out.println("Input field added: " + inputField);，确认非 null；
2. 在actionPerformed()开头加System.out.println("Action triggered!");，确认监听器生效；
3. 如果System.out无输出，立即检查add(inputField)和addActionListener()的执行顺序。

5.3 “新游戏后吊杆没清空，还是上次的残骸”——paint() 方法的幂等性误区

现象：赢了一局，点“New Game”按钮，单词和字母状态重置了，但吊杆还残留着上一局的绳索或头部。

根源：paint()方法被设计为“绘制当前状态”，但它不负责清除画布。AWT 的Graphics对象默认不清屏，每次paint()都是在原有画布上叠加绘制。所以，新游戏时wrongCount归零，但paint()里if (wrongCount >= 4)不执行，之前的绳索线条依然留在内存位图中。

解决方案：在paint()开头，强制清屏：

public void paint(Graphics g) { // 清空背景，避免残留 g.setColor(getBackground()); g.fillRect(0, 0, getWidth(), getHeight()); // 后续吊杆绘制代码... }

fillRect(0,0,width,height)用背景色填充整个画布，确保每次绘制都是干净的起点。这个细节，90% 的初学者会忽略，直到看到“幽灵吊杆”才恍然大悟。它揭示了一个底层事实：GUI 绘图不是“修改对象”，而是“重绘帧”。paint()的职责，永远是“根据当前状态，画出完整画面”，而不是“画出变化的部分”。

5.4 “AppletViewer 窗口一闪而过就关闭”——main 方法缺失的误解

现象：双击HangmanGame.html无反应；在终端执行appletviewer HangmanGame.html，窗口闪现后立即关闭。

根本原因：appletviewer不需要main方法，它直接加载 Applet 类。窗口闪退，通常是init()或start()中抛出了未捕获异常，导致 Applet 初始化失败。

排查步骤：
- 在init()和start()的try-catch外层，加全局异常捕获：
java public void init() { try { // 原有初始化代码 } catch (Exception ex) { ex.printStackTrace(); // 输出到控制台，看清错在哪 JOptionPane.showMessageDialog(this, "Init failed: " + ex.getMessage()); } }
- 常见异常：NullPointerException（某个组件未实例化就使用）、NumberFormatException（字符串转数字失败）、ArrayIndexOutOfBoundsException（单词库索引越界）。

我在教学中，会故意在init()里写一行int x = 10 / 0;，让学生观察窗口闪退后控制台输出的ArithmeticException，从而建立“异常导致 Applet 崩溃”的直观认知。

6. 教学延展与二次开发指南：从读懂到动手改

6.1 三个渐进式改造实验（附代码片段）

实验一：支持小写字母输入
现状：inputField.getText().toUpperCase()强制转大写，但学生输入小写a时，statusLabel显示“Invalid input”，体验割裂。
改造点：在processGuess()开头，增加小写校验：

guess = guess.trim(); // 去除首尾空格 if (guess.length() != 1 || !Character.isLetter(guess.charAt(0))) { statusLabel.setText("Please enter ONE letter!"); return; } guess = String.valueOf(Character.toUpperCase(guess.charAt(0))); // 只转字母

效果：输入a（带空格）、ab、1都会提示，输入a或A都正常处理。这个改动引入了trim()、length()、isLetter()等字符串基础方法，是绝佳的语法练习。

实验二：添加音效反馈（Applet AudioClip）
利用 Applet 内置的AudioClip播放简单音效：

private AudioClip winSound, loseSound; public void init() { // 加载音频资源（需准备 .au 格式文件，Java 原生支持） winSound = getAudioClip(getDocumentBase(), "win.au"); loseSound = getAudioClip(getDocumentBase(), "lose.au"); } private void playWinSound() { if (winSound != null) winSound.play(); } private void playLoseSound() { if (loseSound != null) loseSound.play(); }

在checkWin()成功后调playWinSound()，checkLose()后调playLoseSound()。注意：.au是 Java Applet 唯一原生支持的音频格式，可用在线转换工具将 MP3 转为 AU。这个实验让学生接触资源加载、异步播放、空指针防护（if (sound != null)），且音效带来的即时反馈，极大提升学习成就感。

实验三：词库外部化为文本文件
将硬编码单词库移到words.txt文件：

JAVA APPLET AWT SWING

在init()中读取：

private void loadWords() { try { URL url = getClass().getResource("/words.txt"); // 放在 src/ 目录下 BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream())); List<String> list = new ArrayList<>(); String line; while ((line = reader.readLine()) != null) { if (!line.trim().isEmpty()) list.add(line.trim().toUpperCase()); } words = list.toArray(new String[0]); reader.close(); } catch (IOException e) { System.err.println("Failed to load words.txt: " + e.getMessage()); words = new String[]{"DEFAULT"}; // 降级方案 } }

这个改造涉及getResource()（类路径资源定位）、BufferedReader（IO 流）、异常处理（IOException）、集合转换（List→Array），是通往真实工程的必经之路。关键是，它让学生理解：硬编码是起点，外部化是成长。

6.2 为什么这个项目是 GUI 学习的“元模型”？

最后分享一个观点：这个 Applet 版刽子手，其价值不在于它多先进，而在于它是一个自洽的、最小完备的 GUI 系统原型。它包含了所有 GUI 框架的基因片段：
-状态（State）：word,guessedLetters,wrongCount,gameOver；
-视图（View）：paint()绘制吊杆，statusLabel.setText()更新文字；
-控制器（Controller）：ActionListener响应输入，processGuess()处理业务逻辑；
-生命周期（Lifecycle）：init()初始化，start()启动，paint()渲染，stop()暂停；
-事件（Event）：ActionEvent触发猜测，MouseEvent（可扩展）响应按钮点击。

现代 React 的useState、Vue 的data、Android 的ViewModel，无非是把这些概念包装得更高级、更安全。但内核从未改变：数据驱动 UI，事件触发状态变更，生命周期管理资源。当你把这个 800 行的 Applet 逐行吃透，再去看任何 GUI 框架的文档，你会发现自己不是在学新东西，而是在识别“它把哪部分逻辑封装到哪去了”。这种穿透表象的能力，才是这个古老项目赠予当代学习者最锋利的刀。

我个人在实际教学中发现，学生完成这个项目后，对“MVC 架构”“响应式编程”“状态管理”的理解速度，比直接学框架快 2-3 倍。因为它不教你怎么用轮子，而是带你亲手造一个轮子——哪怕这个轮子，已经停在了历史的博物馆里。

本文还有配套的精品资源，点击获取