简介：一份面向计算机专业毕业生的Java五子棋手机网络对战游戏完整毕设项目，包含可直接运行的软件源码与系统设计文档，适合用于课题研究、课程实践与论文参考。压缩包约5.55MB，以Java源码与论文文档为主，覆盖Java基础、面向对象、GUI界面编程、多线程、Socket网络通信、数据结构与算法、游戏规则逻辑等核心知识点，并涉及版本控制、调试与单元测试实践。项目完整演示了从棋盘绘制、落子操作、胜负判断到双端联机对战的具体实现，并在文档中给出需求分析、系统架构、模块设计、测试计划等规范内容，可辅助撰写毕业设计论文，也能帮助巩固多线程通信中的并发控制与数据同步思路。已有95人浏览学习，适合具备一定Java基础、希望深入网络游戏开发并提升工程能力与文档编写水平的读者。
1. 五子棋手机网络对战：年年有人做，为什么你的毕设只能拿及格
临近毕业季，Java 方向的学生最头疼的事往往不是找工作，而是手上没有一个能拿得出手的项目。选题库里躺着无数个“图书管理系统”和“学生信息管理”，可这些项目面试官早就看腻了。反倒是五子棋这类带网络对战的小游戏，年年出现在毕设参考里，年年都有学生做——因为它规模适中、技术点明确、演示效果好。一个手机能跟另一个手机对弈，过程中涉及界面绘制、事件处理、Socket 通信、多线程协作，恰好把 Java 课程里最核心的知识点都串了起来。
这个标题里的关键并不在“五子棋”三个字，而在“手机网络对战”和“文档说明资料”。换句话说，代码只是载体，你真正要交付的是两样东西：一套能跑通联机对战的系统，以及一套能让老师点头、能让面试官听懂的技术叙述。很多人写完代码就以为完事了，结果答辩时讲不清通信流程，面试时说不明白线程模型，项目白白浪费。这篇文章就按“方案选型 → 棋盘绘制 → 通信协议 → 断线重连 → 答辩话术”的顺序，把这条路上能预见的坑全部趟一遍。
2. 先选型再动手：Swing 客户端加 ServerSocket，够用且能讲清楚
2.1 为什么不用 Web 前端或游戏引擎
第一次做这个题目的人，最容易在技术选型上反复横跳。看到别人用 JavaScript 写得网页版五子棋很漂亮，就想转去做网页；看到 Unity 或 LibGDX 能做出炫酷特效，又想换引擎。我的建议很直接：别换，老老实实用 Java 自带的 Swing 或 JavaFX 做客户端，用 ServerSocket 加 ObjectOutputStream 做网络层。
理由分三层。第一，这是一个毕设项目，不是商业产品。你需要的不是炫技，而是把课堂上教过的东西完整地展示出来。Swing 的 JFrame、JPanel、MouseListener 这些组件，几乎每一本 Java 教材都会讲到，答辩时老师问起来你心里有底。第二，网络对战的核心难点不在界面渲染，而在数据同步和状态管理。用 Web 技术的话，你还要额外处理跨域、WebSocket 协议这些与五子棋无关的问题，等于给自己增加工作量。第三，LibGDX 这类引擎的学习曲线陡峭，你花在搞懂引擎 API 上的时间，足够你把 Socket 编程练熟三遍。
服务器端的选择同样不需要纠结。直接写一个独立的 Java 控制台程序，用 ServerSocket 监听端口，每来一个客户端就开一条线程处理。数据库可选配——如果你想展示 JDBC 技能，可以加一个用户注册登录；如果求稳，用内存存储玩家状态也完全够用。五子棋对战的实时性要求并不高，一次落子消息的延迟在几十毫秒以内玩家就感知不到，ServerSocket 的阻塞 IO 模型完全扛得住。
2.2 工程结构划分：三个模块，各管一摊
动手写代码前，先把包结构定下来。我习惯拆成三个 Maven 模块或三个包：client 管界面和本地棋局状态，server 管连接和消息转发，common 放共享的数据类。这个划分不是形式主义——它直接影响你后面写代码时的思路清晰度，也影响答辩时你怎么跟老师介绍你的系统架构。
gobang ├── client │ ├── ui // 棋盘面板、主窗口、登录界面 │ ├── network // 客户端 Socket 封装、消息收发线程 │ └── core // 棋局逻辑、胜负判定 ├── server │ ├── core // 服务器主入口、端口监听 │ ├── handler // 每个客户端连接对应一个线程 │ └── room // 对局房间管理、匹配逻辑 └── common ├── message // 消息类型枚举、消息对象 └── protocol // 序列化工具、协议常量这个结构最大的好处是职责清晰。common 里的消息类被两端的网络层共同引用，保证序列化时类定义一致；client 的 core 模块不依赖任何 UI 组件，方便你单独写单元测试验证胜负判定算法。我第一次做这个项目时把所有代码堆在几个类里，改一个界面 bug 要翻半天代码，后来拆开重构才意识到模块化的重要性。
2.3 构建最小骨架：先让两人通过服务器搭上线
不要一上来就写棋子绘制和胜负判定，先做最小可行版本：客户端能连接到服务器，服务器能把客户端 A 发的字符串原样转发给客户端 B。这一步通了，整个项目的通信骨架就立住了。先定义消息基类和枚举类型：
// common/message/MessageType.java public enum MessageType { CONNECT, // 连接建立 MATCH_REQUEST, // 请求匹配 MATCH_SUCCESS, // 匹配成功 MOVE, // 落子 GAME_OVER, // 游戏结束 HEARTBEAT, // 心跳 DISCONNECT // 断开连接 } // common/message/GameMessage.java public class GameMessage implements Serializable { private static final long serialVersionUID = 1L; private MessageType type; private Map<String, Object> data; public GameMessage(MessageType type) { this.type = type; this.data = new HashMap<>(); } // getter / setter 省略 }所有消息统一走 GameMessage 对象，用 data 这个 Map 装载业务数据，比如落子坐标、房间号、玩家 ID。这样做的原因是 Java 的 ObjectOutputStream 在序列化时会携带完整的类结构信息，如果你每类消息单独定义一个类，后期加字段容易踩 serialVersionUID 不一致的坑。统一成一个类，字段变更只影响一个文件，重构成本降一个量级。
服务器端的监听逻辑很简单，注意每个连接要独立线程处理：
// server/core/GameServer.java public class GameServer { private ServerSocket serverSocket; private List<ClientHandler> clients = new CopyOnWriteArrayList<>(); public void start(int port) throws IOException { serverSocket = new ServerSocket(port); System.out.println("服务器启动，监听端口：" + port); while (true) { Socket socket = serverSocket.accept(); ClientHandler handler = new ClientHandler(socket, this); clients.add(handler); new Thread(handler).start(); } } }这里的 CopyOnWriteArrayList 是刻意选的——当某个客户端断开时，handler 线程会从 clients 列表里移除自己，而其他线程可能正在遍历列表广播消息。CopyOnWriteArrayList 在遍历时使用快照，不会抛出 ConcurrentModificationException。用 ArrayList 的话，必须在遍历前手动加锁，新手很容易漏掉这个细节。
2.4 序列化传输：为什么我不用纯文本 JSON
客户端和服务器之间的数据传输方式，有两种常见方案：一种是先把对象转为 JSON 字符串，再用 DataOutputStream 写入；另一种是直接用 ObjectOutputStream 写对象。我推荐后者。原因很实在：毕设项目规模小，不需要考虑跨语言通信，Java 原生序列化简单可靠，而且你手写的每条消息类都能实现 Serializable 接口，三行代码搞定。
// client/network/ServerConnector.java public class ServerConnector { private Socket socket; private ObjectOutputStream out; private ObjectInputStream in; private boolean running = true; public void connect(String host, int port) throws IOException { socket = new Socket(host, port); out = new ObjectOutputStream(socket.getOutputStream()); in = new ObjectInputStream(socket.getInputStream()); new Thread(this::receiveLoop).start(); } private void receiveLoop() { while (running) { try { GameMessage msg = (GameMessage) in.readObject(); dispatchMessage(msg); } catch (IOException | ClassNotFoundException e) { running = false; handleDisconnect(); } } } public void sendMessage(GameMessage msg) { try { out.writeObject(msg); out.flush(); } catch (IOException e) { System.out.println("消息发送失败：" + e.getMessage()); } } }注意 receiveLoop 必须跑在独立线程里，因为 ObjectInputStream 的 readObject 是阻塞调用，如果放在 UI 线程里，一旦服务器不推消息，整个界面就卡死。dispatchMessage 再把不同类型的消息转发给 UI 层的回调方法，比如 MOVE 消息就调用 boardPanel 的 updatePiece 方法。
这个阶段你不需要写任何 UI，用控制台验证收发就行。写一个简单的测试：客户端 A 启动后发送“hello”，服务器转发给客户端 B，B 在控制台打印出来。这一步跑通，再往界面上叠加功能。
3. 棋盘绘制与落子交互：把一次点击换算成网格坐标
3.1 Canvas 重绘机制：棋盘必须一次画完
Swing 绘制棋盘的标准做法是继承 JPanel，重写 paintComponent 方法。这里有一个很多人都踩过的坑：paintComponent 会被系统频繁调用，比如窗口拖动、最小化恢复、被其他窗口遮挡后再显示，都会触发重绘。所以你必须把棋盘和所有棋子在这个方法里完整地画一遍，而不是只画新增的部分。
// client/ui/BoardPanel.java public class BoardPanel extends JPanel { private static final int BOARD_SIZE = 15; private static final int CELL_SIZE = 36; private static final int MARGIN = 30; private int[][] pieces = new int[BOARD_SIZE][BOARD_SIZE]; // 0空 1黑 2白 @Override protected void paintComponent(Graphics g) { super.paintComponent(g); // 画网格线 g.setColor(Color.BLACK); for (int i = 0; i < BOARD_SIZE; i++) { g.drawLine(MARGIN, MARGIN + i * CELL_SIZE, MARGIN + (BOARD_SIZE - 1) * CELL_SIZE, MARGIN + i * CELL_SIZE); g.drawLine(MARGIN + i * CELL_SIZE, MARGIN, MARGIN + i * CELL_SIZE, MARGIN + (BOARD_SIZE - 1) * CELL_SIZE); } // 画星位（天元与四个星） drawStarPoints(g); // 画棋子 for (int row = 0; row < BOARD_SIZE; row++) { for (int col = 0; col < BOARD_SIZE; col++) { if (pieces[row][col] != 0) { drawPiece(g, col, row, pieces[row][col]); } } } } private void drawPiece(Graphics g, int col, int row, int player) { int x = MARGIN + col * CELL_SIZE; int y = MARGIN + row * CELL_SIZE; g.setColor(player == 1 ? Color.BLACK : Color.WHITE); g.fillOval(x - CELL_SIZE / 2 + 2, y - CELL_SIZE / 2 + 2, CELL_SIZE - 4, CELL_SIZE - 4); if (player == 2) { g.setColor(Color.BLACK); g.drawOval(x - CELL_SIZE / 2 + 2, y - CELL_SIZE / 2 + 2, CELL_SIZE - 4, CELL_SIZE - 4); } } }画棋子的关键点是坐标换算。鼠标点击时获得的是相对于 JPanel 的像素坐标，而棋盘状态存的是行列索引。换算公式是col = (clickX - MARGIN + CELL_SIZE / 2) / CELL_SIZE，加 CELL_SIZE/2 是为了做四舍五入——点稍微偏移时仍然能落到最近的交叉点上。
3.2 先判定再落子：本地校验与网络校验的分工
落子的流程不能是“收到点击就画棋”，而要分三步：本地校验合法性 → 更新本地棋盘 → 发送消息给对手。前两步之间有一个细节：判定这个位置是否为空，应该在点击事件里做，而不是在 paintComponent 里做。因为 paintComponent 只负责画，它拿到的状态应该是已经合法落子之后的。
// client/ui/BoardPanel.java 添加鼠标监听 public BoardPanel() { addMouseListener(new MouseAdapter() { @Override public void mouseClicked(MouseEvent e) { if (!myTurn || gameOver) return; int col = (e.getX() - MARGIN + CELL_SIZE / 2) / CELL_SIZE; int row = (e.getY() - MARGIN + CELL_SIZE / 2) / CELL_SIZE; if (col < 0 || col >= BOARD_SIZE || row < 0 || row >= BOARD_SIZE) return; if (pieces[row][col] != 0) { System.out.println("该位置已有棋子，请重新选择"); return; } pieces[row][col] = myColor; // 先更新本地状态 repaint(); // 发送网络消息 GameMessage msg = new GameMessage(MessageType.MOVE); msg.getData().put("row", row); msg.getData().put("col", col); ServerConnector.getInstance().sendMessage(msg); myTurn = false; checkLocalWin(row, col); } }); }这里的 myTurn 是一个布尔变量，用于控制回合切换。收到对手的 MOVE 消息时，服务端在转发前先校验对方是合法玩家，然后更新 pieces 数组并调用 repaint。本地校验只管“这个位置没棋子”这一件事，真正的胜负判定在每次落子后都做一遍，但只需要检查以当前落子位置为中心的四条线。
3.3 双线程下的界面刷新：SwingUtilities.invokeLater 的用法
收发网络消息的线程和 UI 线程是两个线程，直接在线程里调用 repaint 会出乱子。Swing 组件不是线程安全的，你必须在事件调度线程里更新界面。解决办法是 SwingUtilities.invokeLater：
// client/network/MessageDispatcher.java public void dispatchMessage(GameMessage msg) { switch (msg.getType()) { case MOVE: int row = (int) msg.getData().get("row"); int col = (int) msg.getData().get("col"); SwingUtilities.invokeLater(() -> { boardPanel.placeOpponentPiece(row, col); boardPanel.setMyTurn(true); }); break; case GAME_OVER: SwingUtilities.invokeLater(() -> { JOptionPane.showMessageDialog(frame, "游戏结束，你" + (msg.getData().get("winner").equals(myName) ? "赢了" : "输了")); }); break; // 其他消息类型处理 } }这个细节答辩时讲到就是加分项。老师问“多线程下界面刷新怎么保证安全”，你能答出事件调度线程机制，说明你真的理解了 Swing 的工作原理，而不是只会拖控件。invokeLater 的作用是把界面的更新操作排队交给事件调度线程执行，从而避免两个线程同时对组件状态做修改。
4. 网络对战协议设计：消息类型、粘包处理与房间匹配
4.1 消息类型枚举：每一类消息各管什么事
通信协议是整个系统的核心，协议设计得好不好，直接决定后续开发的顺不顺畅。我最终定的消息类型包含连接、匹配、落子、结束、心跳、断开六类，每一类的 data 字段都有固定约定：
| 消息类型 | 发送方向 | data 关键字段 | 说明 |
|---|---|---|---|
| CONNECT | 客户端→服务器 | playerName | 客户端连接后立即上报玩家昵称 |
| MATCH_REQUEST | 客户端→服务器 | 无 | 进入匹配队列等待对手 |
| MATCH_SUCCESS | 服务器→客户端 | roomId, color | 匹配成功，color 为 1（黑）或 2（白） |
| MOVE | 客户端→服务器 | row, col | 落子坐标，服务器负责转发给对手 |
| GAME_OVER | 服务器→客户端 | winner | 胜负结果 |
| HEARTBEAT | 双向 | timestamp | 心跳保活，双方检验连接状态 |
| DISCONNECT | 双向 | reason | 主动断开或异常掉线 |
CONNECT 和 MATCH_REQUEST 分开设计是有原因的。连接建立后玩家可能不会立刻点击“开始匹配”，这段时间服务器需要知道当前有多少闲置连接；而匹配成功后,服务器下发 MATCH_SUCCESS 消息，其中 color 字段表明先手后手——先手执黑，后手执白。这个细节如果像某些项目一样用“先连接的就是黑棋”来决定先后手，一旦匹配队列里有三个玩家就会产生逻辑漏洞。
4.2 ObjectOutputStream 的粘包与序列化阻塞：两个必踩的坑
很多人写 Java Socket 通信没听过“粘包”这个词，因为它是 Netty 那类 NIO 框架里才重点讨论的问题。但用 ObjectOutputStream 依然有一个类似的坑：ObjectOutputStream 会缓存头信息，连续快速发送两条消息时，第二条消息的流头可能没有刷新，导致对端 readObject 读到空数据。
// server/handler/ClientHandler.java 发送消息的正确姿势 public void sendMessage(GameMessage msg) { synchronized (writeLock) { // 同一连接的写操作要加锁 try { out.writeObject(msg); out.flush(); // 每次发送必须强制刷新 out.reset(); // 重置缓存，避免引用复用 } catch (IOException e) { System.out.println("发送失败：" + e.getMessage()); } } }第二个坑是 out.reset() 这行代码。ObjectOutputStream 内部维护一个引用表，同一个对象第二次写入时，它不会重新完整地序列化，而是只写入一个引用标记。如果你的 GameMessage 对象在 data 字段里放了一个新创建但不重写的集合对象，可能导致对端反序列化时拿到旧数据。处理办法就是每次写完后调用 reset 清空引用表，同时用 synchronized 把同一 Socket 的写操作串行起来，避免两条线程同时调用 writeObject 把字节流写乱。
4.3 服务器转发模型：单点转发还是广播
因为只支持两个人对战，服务器的转发逻辑不需要广播，只要维护房间映射关系即可。每个房间存两个 ClientHandler，收到 MOVE 消息就往对手的 Socket 写。但要注意一种情况：客户端 A 落子后，服务器先收到 A 的消息，转发给 B，与此同时 B 也落子了，两条 MOVE 消息在服务器交织。处理方式是在房间类里加一个简单的同步锁：
// server/room/BattleRoom.java public class BattleRoom { private ClientHandler blackPlayer; private ClientHandler whitePlayer; private Object moveLock = new Object(); public void handleMove(ClientHandler sender, GameMessage msg) { synchronized (moveLock) { ClientHandler target = (sender == blackPlayer) ? whitePlayer : blackPlayer; msg.getData().put("from", sender.getPlayerName()); target.sendMessage(msg); } } }这个锁不是防止两条 MOVE 消息同时到达——实际上由于两个客户端各自维护 myTurn 布尔值，正常流程下不会出现同时落子。它防的是意外情况：对端网络抖动导致客户端状态不同步，双方都认为自己该落子了。锁住转发过程虽然不能修复逻辑冲突，但至少保证服务器不会同时向两个方向写消息造成线程交叉。
4.4 匹配环节：简单队列做到先进先出
匹配算法的实现可以很基础：一个 ArrayList 做等待队列，新玩家加入时检查队列是否为空，非空则取出首元素组成对局，否则把当前玩家加入队尾。不需要做 ELO 积分匹配——毕设场景里同时在线人数可能只有个位数，做积分反而会让测试时匹配不到人。
// server/room/MatchMaker.java public class MatchMaker { private Queue<ClientHandler> waitingQueue = new LinkedList<>(); public synchronized void addToQueue(ClientHandler handler) { waitingQueue.offer(handler); System.out.println("玩家 " + handler.getPlayerName() + " 进入匹配队列，当前队列长度：" + waitingQueue.size()); if (waitingQueue.size() >= 2) { ClientHandler first = waitingQueue.poll(); ClientHandler second = waitingQueue.poll(); createRoom(first, second); } } }匹配成功后，服务器创建 BattleRoom，把两个 handler 关联到房间，并分别发送 MATCH_SUCCESS 消息。注意先出队的玩家是黑棋先手，这个顺序要写清楚，否则客户端两个人都收到 color=1 就乱套了。
5. 断线重连与状态同步：五子棋联机最容易翻车的一环
5.1 为什么对局中断线比输棋更常见
网络对战项目在演示时最尴尬的场景不是一方把另一方下赢了，而是中途有人断网或锁屏导致连接断开，整个对局卡死。手机连着 Wi-Fi 走动几步，信号切换一下，Socket 连接就可能断了。更麻烦的是，断开的瞬间对端程序不会立刻感知，你可能还在傻等对方落子，界面就停在那里不动了。
这个问题必须在协议层解决，靠 UI 层的“等待提示”只是治标。核心机制是心跳检测：客户端每 3 秒向服务器发送一个 HEARTBEAT 消息，服务器收到后记录最后心跳时间。服务器起一个后台定时任务，每 5 秒扫描所有连接，如果某个连接超过 10 秒没有心跳，就判定它已经断开。
// server/core/HeartbeatMonitor.java public class HeartbeatMonitor implements Runnable { private static final int TIMEOUT_SECONDS = 10; private GameServer server; @Override public void run() { while (true) { try { Thread.sleep(5000); long now = System.currentTimeMillis(); for (ClientHandler handler : server.getClients()) { long lastHeartbeat = handler.getLastHeartbeatTime(); if (now - lastHeartbeat > TIMEOUT_SECONDS * 1000) { System.out.println("心跳超时，断开连接：" + handler.getPlayerName()); handler.close(); server.removeClient(handler); notifyOpponentDisconnected(handler); } } } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } } }5.2 断线后的三种处理策略
断线检测到了，下一步怎么办？有三种可选策略。第一种最简单：直接判负，另一方获胜。适合纯娱乐场景，但体验很生硬——对方只是地铁上信号不好，没来得及重连就输了。第二种是等待重连：服务器保留房间和棋局状态 60 秒，如果断线玩家在这段时间内重新连接并携带原房间号，就恢复对局；超时未重连则判负。第三种是托管：断线玩家的棋子由服务器自动落子，但这样反而让对手赢得莫名其妙，我不推荐。
我建议做第二种，难度不高但效果很好。实现时需要在服务器保存棋局的完整状态：当前棋盘数组、轮到谁、双方玩家名。这些数据本来就在 BattleRoom 里，断线时把房间标记为“等待重连”即可。客户端检测到连接断开后，弹窗提示“连接断开，正在尝试重连”，每 2 秒尝试一次重新 connect。
// client/network/ReconnectManager.java public class ReconnectManager { private int maxAttempts = 30; private int attempt = 0; public void startReconnect(String host, int port, String roomId) { new Thread(() -> { while (attempt < maxAttempts) { try { Thread.sleep(2000); Socket socket = new Socket(host, port); // 连接成功后发送 REPLAY 消息带上原房间号 GameMessage msg = new GameMessage(MessageType.RECONNECT); msg.getData().put("roomId", roomId); msg.getData().put("playerName", playerName); // 发送并等待服务器的 RECONNECT_SUCCESS break; } catch (IOException | InterruptedException e) { attempt++; } } }).start(); } }5.3 常见问题排查：五个让新手卡壳的现场
现象一：客户端报 ClassNotFoundException。原因是客户端和服务器端的 common 包版本不一致，GameMessage 类的 serialVersionUID 被改动过。解决：确认两端的 common 目录用的是同一份源码，不要手工复制粘贴，用 Maven 打成 jar 包统一引用。
现象二：落子后对手收不到消息，但本地界面正常。原因大概率是服务器转发时 target 判断错了方向——sender 和 receiver 比较时用了 equals 而没重写 hashCode，比较失败。解决：ClientHandler 里用 playerName 做唯一标识，或者在 BattleRoom 建立时保存两个 handler 的引用直接用 == 比较。
现象三：连续快速落子时，第二颗棋子显示的位置是上一颗棋子。原因就是前面说的 ObjectOutputStream 缓存导致数据没及时刷新。解决：确认每次 sendMessage 都调用了 out.reset()，并且同一 Socket 的写操作加了锁。
现象四：客户端启动后界面白屏，过几秒才出现。原因是网络接收线程的阻塞操作影响了 Swing 初始化的时机。解决：初始化界面不要等待网络连接，先构建完整的 JFrame 和棋盘，网络连接在后台线程异步建立。
现象五：服务器端口被占用，启动直接报 BindException。解决方式有两种,要么换端口号，要么杀掉占用进程。Windows 上查找占用进程的命令是netstat -ano | findstr 8888，然后taskkill /PID 进程号 /F。macOS/Linux 用lsof -i :8888找到进程号再 kill。
5.4 状态不同步的根源：双向校验点位合法性
还有一个逻辑层面的坑：客户端 A 落子坐标为 (7,7)，消息到达服务器后直接转给客户端 B。如果这条消息是通过抓包或手动构造发送的，坐标可能是一个已经被占用的位置，B 的界面就会画出一个重叠的棋子。线上环境里没人会这么做，但为了代码健壮性，服务器应该在转发前做一次校验——检查坐标是否越界、该位置是否为空。
// server/room/BattleRoom.java 增加校验 public boolean isValidMove(int row, int col) { if (row < 0 || row >= 15 || col < 0 || col >= 15) return false; if (board[row][col] != 0) { System.out.println("非法落子：该位置已有棋子 (" + row + ", " + col + ")"); return false; } return true; }服务器维护一份与两端同步的棋盘数组，在转发 MOVE 前先更新服务器自己的棋盘，合法才转发。这样一来，即使两个客户端的状态出现偏差，服务器端的校验也能兜住。
6. 把项目讲出亮点：答辩和面试中真正值钱的三个设计点
代码写完了，工作其实还剩一半。同一份五子棋项目，有人答辩被老师质疑“工作量不够”，有人能借此拿到 Java 开发的 offer,差别就在于你会不会把设计亮点讲出来。结合前面实现的代码，我建议你从三个维度准备讲稿。
第一个亮点是“阻塞 IO 模型下的线程隔离”。你能讲清楚为什么客户端要分 UI 线程、接收线程、发送线程，以及它们各自阻塞在哪里。面试官问“Java 中有哪几种实现并发的方式”，你直接举例说明自己项目里用到了 Thread 加 Runnable 接口、线程池调度心跳扫描任务、synchronized 同步写操作，就比背八股文生动得多。
第二个亮点是“序列化与协议设计”。很多学生用 JSON 传数据但讲不清为什么选 JSON；你用的是 Java 原生序列化，要能说清 ObjectOutputStream 的引用缓存机制、reset 的作用、serialVersionUID 的重要性。面试官追问“如果要把客户端改成 Android 原生应用，通信协议怎么兼容”，你就说把 GameMessage 的结构保持不动，两端用 JSON 解析——因为你当初把 data 设计成 Map 而不是固定字段，天然就能适配。
第三个亮点是“断线重连的工程思维”。大多数毕设不会处理断线重连，你做了，就已经超过了一部分人。讲的时候要说清楚心跳超时的阈值为什么定 10 秒而不是 3 秒——太短则网络抖动会导致误判，太长则玩家等待恢复的时间过久。这种带数字权衡的讲述，正是面试官想看到的思考深度。
最后一个实践建议：演示前一定跑一遍两人对战全流程。我当年第一次演示时，两台手机连同一个 Wi-Fi，结果路由器开了 AP 隔离，两个客户端根本 ping 不通。后来我直接在代码里加了局域网 IP 自动探测，服务器启动时打印本机 IP，客户端启动时可选“自动发现服务器”。这个功能不算大，但现场演示时特别有用，能让你少一次当众翻车的机会。
整理好你的文档说明资料，把上述三个亮点作为“系统设计”章节的重点，把断线重连作为“创新点”单独列一节。五子棋本身不是新东西，但你把通信机制做扎实了，把边界条件处理好了，老师也好、面试官也好，都会愿意给你一个不错的评价。希望帮到你。
本文还有配套的精品资源，点击获取
