网络对战游戏平台毕设：Socket通信与报文协议实战解析

简介：面向计算机软件专业本科毕业设计的参考文档，提供网络对战游戏平台系统从需求分析、总体设计到编码测试的完整方案。文档以C++结合MFC框架与MySql数据库为技术主线，重点阐述用户管理、游戏大厅和五子棋网络对战三大模块的实现细节，并给出系统功能结构、数据库设计、Socket通信机制及TCP/UDP协议选型等关键技术内容。资源包内仅1个doc文件，体积682KB，为Word格式文档，可直接打开阅读或二次编辑，适合毕业生、在校生作为网络编程类课设或毕设的写作蓝本。目前已有142人学习浏览，说明该案例具备一定参考热度。读者可以从中获得需求分析思路、系统架构分层、关键代码逻辑、数据库表设计及测试分析方法，尤其适合想在较短时间内建立“客户端-服务器”对战平台整体认知的C++开发者。

1. 网络对战游戏平台：这套毕设真正卡人的地方不在游戏，在通信

「网络对战游戏平台系统设计」在计算机软件毕业设计题目里出现频率非常高，但很多人拿到题后第一反应是去做游戏界面，做着做着才发现，真正卡住自己的不是界面，而是两个程序之间怎么稳定地收发消息。这个题目表面上是做一个能登录、能匹配、能对战的平台，内核其实是三件事：一套能承载所有业务的消息协议，一个能同时管住几十个连接的服务端，一条从登录到对战的完整联调链路。任何一个环节没跑通，演示的时候都会当场翻车。这个题目适合正在做毕设的在校生，也适合想用一个小型网络项目把 Socket、多线程、数据库串起来练一遍的应用型开发者。它最大的价值不是游戏多好玩，而是把「两台电脑上的程序怎么互相通信」这件事彻底跑明白。

2. 架构与通信选型：先定 C/S 骨架，再把报文协议做成所有功能的通用语言

2.1 为什么选 C/S 而不是 B/S：你要的是一条能双向推消息的长连接

对战平台的核心诉求是低延迟和实时推送。登录结果、对手走棋、聊天消息这些数据，服务端要主动往客户端推，而不是等客户端来问。HTTP 的典型一问一答模式在这里会很别扭：要么客户端疯狂轮询制造大量无效请求，要么上 WebSocket——但 WebSocket 本身又是一套额外的协议和框架。对毕设来说，TCP Socket 长连接是最直接、最能把原理讲清楚的选择。服务端 accept 之后保持连接不关，双方随时可以往对方写数据，双向主动推送天然成立。

客户端形态方面，我见过不少选型：Unity 写对战客户端、网页端做大厅、微信小程序做战绩查询。但对「网络对战游戏平台」这个题目来说，最稳妥的搭配是 Java Swing 客户端加 Java Socket 服务端，中间走自定义的 TCP 报文协议，数据库用 MySQL。理由很实在：Swing 和 Socket 都是 JDK 自带的能力，不需要引入额外的通信框架，答辩时可以从 Socket 底层一路讲到界面事件，逻辑闭环完整。如果选 Netty，当然更专业，但框架封装掉了太多细节，反而不好展示你对网络编程基础的理解。对这个体量的题目，我的建议是：先不用框架，把每个环节亲手写一遍。

选型确定后，要立刻定义清楚「消息」这个概念。对战平台里所有指令——登录请求、登录响应、创建房间、加入房间、对局移动、聊天、心跳——本质都是「一个消息类型加一段业务内容」。我一般会先定义一份消息类型清单，写在代码常量里，也写进论文的协议设计章节：

public class MessageType { public static final byte LOGIN_REQUEST = 1; // 客户端 -> 服务端：登录 public static final byte LOGIN_SUCCESS = 2; // 服务端 -> 客户端：登录成功 public static final byte LOGIN_FAIL = 3; // 服务端 -> 客户端：登录失败 public static final byte CREATE_ROOM = 4; // 客户端 -> 服务端：创建房间 public static final byte JOIN_ROOM = 5; // 客户端 -> 服务端：加入房间 public static final byte ROOM_INFO = 6; // 服务端 -> 客户端：房间信息 public static final byte BATTLE_MOVE = 7; // 双方对局中的操作指令 public static final byte CHAT = 8; // 聊天消息 public static final byte HEARTBEAT = 9; // 心跳包 public static final byte KICK_OFF = 10; // 踢下线通知 }

类型清单不是随便列几个数字，它决定了后面所有代码的 switch 分支。每新增一个业务功能，第一步是在这里加一个常量，第二步才是写处理逻辑。我习惯把协议类型常量单独放一个类，避免散落在各个 Handler 里，后面查消息路由的时候只需要看这一个文件。

C/S 架构还有一个隐藏优势：对网络环境的要求低。自己做开发时，服务端和客户端可以都跑在本机的回环地址上，演示的时候再把客户端挪到局域网另一台电脑，整个迁移不需要改任何业务代码，只需要改一个 IP 参数。这一点在毕设答辩现场特别重要——现场网络往往不靠谱，能单机演示是底线保障。

2.2 报文协议设计：8 字节头部 + UTF-8 内容，粘包半包一次解决

TCP 是流协议，没有消息边界。你 write 两次消息，对方 read 的时候可能一次读走两条，也可能一条被拆成两截，这在网络编程里叫粘包和半包。解决思路不是靠运气，而是给每条消息加一个固定格式的头部，头部里写明消息体长度。接收方先填满头部，解析出长度，再按这个长度把消息体完整读出来。

我常用的一版报文格式是：2 字节魔数 + 1 字节版本号 + 1 字节消息类型 + 4 字节消息体长度 + 消息体字节。魔数用于快速识别非法连接，版本号给将来协议升级留余地，消息类型决定这个消息交给哪个业务逻辑处理，长度字段解决粘包拆包。消息体统一用 UTF-8 编码的 JSON 或 KV 文本。对毕设业务来说，消息体不需要压缩，直接用 JSON 字符串最省事，方便打印日志调试。

import java.io.*; import java.nio.charset.StandardCharsets; public class Protocol { public static final int HEAD_LEN = 8; public static final short MAGIC = 0x4F51; // 魔数：OJQ 的 ASCII 简化取值 public static void write(OutputStream out, int type, String body) throws IOException { byte[] bodyBytes = body.getBytes(StandardCharsets.UTF_8); DataOutputStream dos = new DataOutputStream(out); dos.writeShort(MAGIC); // 2 字节魔数 dos.writeByte(1); // 1 字节协议版本 dos.writeByte(type); // 1 字节消息类型 dos.writeInt(bodyBytes.length); // 4 字节消息体长度 dos.write(bodyBytes); // 消息体 dos.flush(); } public static Message read(InputStream in) throws IOException { DataInputStream dis = new DataInputStream(in); short magic = dis.readShort(); if (magic != MAGIC) { throw new IOException("bad magic: " + magic); } dis.readByte(); // 版本号，当前暂不校验 byte type = dis.readByte(); int len = dis.readInt(); byte[] body = new byte[len]; dis.readFully(body); // 读满 len 字节，避免半包 return new Message(type, new String(body, StandardCharsets.UTF_8)); } }

这个类是整个平台的通信地基，所有收发都走它。write 方法负责把业务数据包装成一条完整报文，read 方法负责从输入流里精准还原出消息。重点看 dis.readFully(body) 这一行——它和 dis.read(body) 的区别在于，readFully 会阻塞到把 len 个字节全部读完才返回，read 则可能只读一部分就返回。读过半包的都知道，这里用错方法，消息体就会莫名其妙少一截，而且时好时坏，非常难查。

协议里另一个容易被低估的参数是魔数。服务端 accept 一个连接后，可以先试着读 2 字节校验魔数，不对直接关连接，能挡掉一批乱连的端口扫描器。对毕设来说，这个细节还能写进论文的安全性设计部分。版本号字段建议保留，哪怕你只实现了版本 1，写清楚协议演进规则，答辩老师追问时你也有话可说。

2.3 数据库表设计：用户、对局、战绩怎么落库，哪些数据只许待在内存

对战平台的业务数据要分清两类：一类是必须在数据库里留痕的，比如用户账号、对局记录、战绩统计；另一类只活在内存里，比如当前在线用户、房间列表、某场对局的实时状态。把内存数据硬往数据库里写，是新手最容易犯的错——每走一步棋都 UPDATE 一次数据库，不仅慢，还会让代码逻辑变得乱七八糟。

账号和战绩落在 MySQL。最核心三张表：用户表存登录凭证和基础资料，对局记录表存每一场对战的时间、双方玩家、胜负、回合数，战绩表可以冗余一份聚合数据，避免每次查战绩都现算。

CREATE TABLE `t_user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(32) NOT NULL UNIQUE, `password` VARCHAR(64) NOT NULL, `nickname` VARCHAR(32) DEFAULT '', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `t_game_record` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `room_id` INT NOT NULL, `player_a` INT NOT NULL, `player_b` INT NOT NULL, `winner` INT DEFAULT NULL, `total_rounds` INT DEFAULT 0, `played_at` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `t_user_stat` ( `user_id` INT PRIMARY KEY, `total_games` INT DEFAULT 0, `win_games` INT DEFAULT 0, `lose_games` INT DEFAULT 0 );

用户表里建议直接用自增 id 做关联，而不是拿 username 当主键。因为玩家改名、聊天展示、对局记录都要引用用户，id 是整数，索引快，关联也清爽。密码字段存 SHA-256 摘要而不是明文，这是安全底线的要求，哪怕毕设也不能把明文密码直接落库。对局表里的 player_a、player_b 都引用 t_user.id，winner 同样引用用户 id，为 null 表示平局或未完成。

在线用户、房间、当前对局状态这些数据，用 ConcurrentHashMap 放在服务端进程里就够了。登录时把 userId 映射到连接会话对象，创建房间时把房间号映射到房间对象。为什么强调 ConcurrentHashMap？因为服务端是多线程的，每个客户端连接占一个线程，这些线程会同时读写在线表和房间表，用普通 HashMap 轻则数据不一致，重则直接死循环。这一条是踩过坑才记住的，后面避坑章节里细说。内存数据和数据库的边界就一句话：需要跨重启保留的进库，实时协作数据留内存。

3. 服务端三条主流程：登录、大厅广播、对战房间的中继与裁决

3.1 服务端线程模型：每连接一线程，规模小但逻辑最直白

服务端启动后要做的事很简单：在指定端口创建一个 ServerSocket，然后不停地 accept 新连接。每个连接进来，单独分配一个线程去处理，这就是经典的每连接一线程模型。这种模型的缺点是线程数随连接数线性增长，几千个连接就会撑不住；但对毕设场景——在线人数几十人——完全够用，而且代码最好理解，调试最方便。我见过有人一上来就上 Netty 或者 Java NIO 的 Selector，结果光是理解事件循环就花了好几天，最后项目没跑通。先把简单的模型跑起来，再谈优化。

public class GameServer { private ServerSocket serverSocket; private final Map<Integer, ClientSession> onlineUsers = new ConcurrentHashMap<>(); private final RoomManager roomManager = new RoomManager(); public void start(int port) throws IOException { serverSocket = new ServerSocket(port); System.out.println("server started on port " + port); ExecutorService pool = Executors.newCachedThreadPool(); while (true) { Socket socket = serverSocket.accept(); pool.submit(new ClientHandler(socket, this)); } } }

accept 方法会阻塞，直到有新连接进来。每来一个连接，就用线程池提交一个 ClientHandler，Handler 负责读取这条连接上的所有消息并路由到对应业务逻辑。用 newCachedThreadPool 而不是手动 new Thread，好处是线程可以复用，连接断开后线程归还池子而不是销毁。线程池还有个隐藏优势：你可以通过配置最大线程数来限制服务端的资源占用，防止某台机器上连进来几十个测试连接就把内存打爆。线程数上限我一般设 200，对毕业设计来说非常宽裕。

ClientHandler 的核心是那条循环：不断调用 Protocol.read 读取消息，读到一条就按消息类型分发。read 方法内部用的是阻塞 IO，连接上没有数据时线程会挂起等待，这是正常的，不需要额外处理。真正要注意的是循环的退出条件：客户端正常关闭时，read 会抛出 EOFException 或返回异常，这时要捕获并清理这个会话占用的资源，比如从在线表移除、把玩家踢出房间。这个清理动作写不写、写得对不对，决定了服务端会不会出现「人走了但在线列表还挂着」的诡异情况。

3.2 登录与掉线处理：在线表、异地登录、上下线广播

登录流程是整个平台的第一个完整闭环。客户端发起连接后，立刻发一条 LOGIN_REQUEST，内容用简单的 KV 格式：username=zhangsan&password=xxx。服务端收到后查库校验，成功就把这个连接绑定为在线状态，加入在线表；失败就回一条 LOGIN_FAIL。登录成功后，还要把最新的在线用户列表广播给所有在线客户端，这样大厅里每个人都能看到谁在线。

private void handleLogin(ClientSession session, String body) { String[] parts = body.split("&"); String username = parts[0].split("=")[1]; String password = parts[1].split("=")[1]; User user = userDao.findByUsernameAndPassword(username, DigestUtils.sha256Hex(password)); if (user == null) { session.send(MessageType.LOGIN_FAIL, "用户名或密码错误"); return; } ClientSession old = onlineUsers.get(user.getId()); if (old != null) { old.send(MessageType.KICK_OFF, "账号在其他地方登录"); old.close(); } session.bindUser(user); onlineUsers.put(user.getId(), session); broadcastLobbyUsers(); }

异地登录的处理值得单独说说。如果不踢掉旧连接，同一个账号会同时在线，对战时会出现「自己走了一步，另一个人也走了一步」的数据错乱。常见做法是后登录的顶掉先登录的：给旧连接发一条 KICK_OFF 消息，然后关闭它的 socket。旧连接的 Handler 线程会因为 socket 关闭而退出循环，触发资源清理。这个设计在论文的「系统健壮性」部分可以写上一笔，答辩老师通常会追问。

在线用户列表的广播要控制频率，不要每次变化都全量广播所有数据。我一般只广播一个精简列表：[{id:1,nickname:'张三'},{id:2,nickname:'李四'}]，客户端收到后自己更新大厅名单。如果聊天、头像、战绩都在列表里，数据量会膨胀好几倍，没这个必要。掉线清理要放在 finally 块里执行——不管线程是正常退出还是被异常打断，都要把用户从在线表和房间中移除，这一步漏了，后面避坑章节里提到的「幽灵账号」就会出现。

3.3 对战房间：创建、加入、对局中继、结果上报

对战流程是平台的核心亮点，实现上分为四个阶段：创建房间、加入房间、对局中继、结果上报。房间数据活在服务端内存里，一个房间对象里记录房主、对手、房间状态（等待中、对战中、已结束）、当前回合数。同一时刻一个玩家只允许在一个房间里，加入别人的房间前要先检查自己是不是已经在别的房间，否则会出现一个玩家同时在两场对局里的逻辑错误。

public class Room { private final int roomId; private final ClientSession owner; private ClientSession guest; private volatile int state; // 0 等待中 1 对战中 2 已结束 public ClientSession getOpponent(ClientSession me) { return me == owner ? guest : owner; } }

对局中继是整个平台最体现网络编程思路的地方。以五子棋为例，A 落子后，客户端把坐标发给服务端，服务端收到后要做两件事：一是校验这个坐标合不合法（有没有出界、是不是已经被占），二是把 A 的操作转发给 B。服务端做裁决而不是只当中转，能防止客户端作弊——直接信任客户端上报的结果，等于告诉别人可以改包。这部分的完整代码较长，但核心转发逻辑就那么几行：

private void handleBattleMove(ClientSession session, String body) { Room room = session.getRoom(); if (room == null || room.getState() != 1) { session.send(MessageType.ERROR, "当前不在对战中"); return; } ClientSession opponent = room.getOpponent(session); if (opponent != null) { opponent.send(MessageType.BATTLE_MOVE, body); } }

对局中继有个容易忽略的细节：B 收到 BATTLE_MOVE 后应该回一条确认给服务端吗？如果完全不回，服务端就无法知道 B 是否真的收到了这一步。但如果每一步都要求确认再继续，又会把对局延迟拉高。折中方案是把确认做成「动作 ACK」：B 的客户端收到移动指令后更新棋盘并回一个 ACK，服务端收到 ACK 后才允许同一房间内的下一步操作。对五子棋、象棋这类回合制游戏，这个机制足够可靠；如果是实时动作类游戏，就得换思路去做帧同步，后面进阶章节会提到。

结果上报阶段要落库。对局结束，胜利方客户端发送结束请求，服务端根据自己记录的对局状态和双方操作历史做最终裁决，确认胜负结果后写 t_game_record，同时更新双方用户的战绩表。注意这里不能只信客户端单方面上报的胜负，要以服务端裁决为准，否则就会出现「两边都说自己赢了」的翻车现场。

4. 客户端联调：先用 Swing 跑通完整链路，再考虑美化

4.1 客户端通信层：连接参数、发送消息、收包线程三件事

客户端这边的代码结构比服务端简单，但要处理好一个重要问题：收到消息后怎么更新界面。Swing 是单线程模型，所有界面更新必须在事件分发线程（EDT）里执行。网络收包线程收到消息后不能直接去改 JLabel 的文本，要交给 SwingUtilities.invokeLater 投递到事件队列里。不做这一步，界面上会随机出现一些奇怪的刷新问题，时好时坏。

public class TcpClient { private Socket socket; private DataInputStream in; private DataOutputStream out; private volatile boolean running = true; public void connect(String host, int port) throws IOException { socket = new Socket(); socket.connect(new InetSocketAddress(host, port), 3000); in = new DataInputStream(socket.getInputStream()); out = new DataOutputStream(socket.getOutputStream()); new Thread(this::receiveLoop, "receive-thread").start(); } public void send(int type, String body) throws IOException { Protocol.write(out, type, body); } private void receiveLoop() { while (running) { try { Message msg = Protocol.read(in); SwingUtilities.invokeLater(() -> handleMessage(msg)); } catch (IOException e) { running = false; SwingUtilities.invokeLater(this::onDisconnected); } } } }

connect 时设置的 3000 毫秒是连接超时，超过这个时间连不上就直接抛异常，提示用户检查服务端是否启动、IP 和端口是否写对。receiveLoop 是一个死循环线程，专门负责收消息，收不到就阻塞在 Protocol.read 里。一旦连接断开，read 会抛 IOException，线程把 running 置为 false 并通知界面层做出提示。注意 running 是 volatile 的，因为它在收包线程里写、在界面的关闭按钮事件里读，多线程可见性要靠 volatile 保证。

消息处理函数 handleMessage 里是一个大的 switch 分支，按消息类型分发给各个界面的更新方法。LOGIN_SUCCESS 就切换到大厅面板，ROOM_INFO 就刷新房间列表，BATTLE_MOVE 就更新棋盘。这里设计一个小技巧：把每个业务消息对应的 UI 更新方法单独抽出来，不要全部堆在 switch 里，后面加功能、改界面的时候会好改很多。哪怕是毕设项目，也值得保持最基本的整洁。

4.2 联调参数清单与双客户端验证步骤

联调是整个项目最花时间的阶段，有一个清单能少走很多弯路。我最常用的一组参数是：服务端监听 0.0.0.0，端口 8888；客户端连接超时 3000 毫秒；心跳间隔 5 秒；服务端读超时 15 秒；消息体上限 64 KB。这些参数都直接写死成常量，放在配置类里，不要散落在各个代码文件中。

验证时不要直接跳到最后一步，按流程走一遍最稳妥。我的习惯是在本机先启动服务端，再启动两个客户端实例，用两个不同账号登录。登录成功后确认大厅在线列表里能看到两个账号，然后 A 创建房间，B 加入房间，双方在房间里发几句聊天确认消息互通。进入对战环节，A 走一步，观察 B 的棋盘是否更新；B 再走一步，观察 A 的棋盘。最后一方认输，确认服务端日志里记录了本场对局，数据库里能查到这场对局的记录。每一步都确认通过，整个链路才算真正打通。

联调过程中服务端的日志至关重要。我习惯在每条消息的读写处打印一行结构化日志，格式类似[15:23:01] type=4 body={"roomId":1001}，这样消息走到哪一步、有没有被错误分发，一眼就能定位。客户端这边不用打那么详细，重点记录连接状态和登录结果就够了。日志打印会拖慢一点性能，但对联调阶段来说，可观测性远比性能重要。

4.3 心跳与异常断开：让服务端能及时知道「人不在了」

正常关闭客户端时，操作系统会发送 FIN 包，服务端 read 会返回 -1 或者抛异常，服务端能立刻知道连接断开。但现实里很常见的情况是：客户端直接杀进程、拔网线、或者网络闪断，这时候服务端是感知不到的，它以为这条连接还活着，在线列表里那个人也一直显示在线。解决这个问题的标准方案是心跳机制，客户端每隔固定时间发一个心跳包，服务端维护每个连接的最后活跃时间，超过阈值没收到任何数据就判定掉线，主动关闭连接并清理资源。

// 客户端：启动一个定时任务，每 5 秒发一次心跳 ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(() -> { try { client.send(MessageType.HEARTBEAT, "ping"); } catch (IOException ignored) { // 连接已断开，发送失败不需要在这里处理 // 收包线程那边会统一处理断线回调 } }, 5, 5, TimeUnit.SECONDS); // 服务端：每个会话初始化时设置 15 秒读超时 socket.setSoTimeout(15_000);

服务端不用为心跳单独写业务逻辑，因为 TCP 层收到任何数据都会重置读超时，心跳包本身到达即可说明连接活着。但有一个细节要处理好：如果服务端读超时触发，抛的是 SocketTimeoutException，这个异常和连接断开的 IOException 不同，后者要清理整个会话，前者只要关掉这个超时的连接再清理即可。我一般把超时和断开统一按掉线处理，因为连接既然 15 秒都没有任何数据，留着也没意义，直接清理最干脆。

心跳间隔和读超时的时间参数设置要留出余量。心跳 5 秒，读超时如果只设 8 秒，网络稍微抖动一下就会误杀正常玩家；设 30 秒，掉线后在线列表上的人要等半分钟才能被清掉，演示时非常尴尬。我的习惯是心跳间隔 5 秒，读超时 15 秒，即 3 个心跳周期没动静就判定掉线。这个比例既能容忍偶尔的几次网络抖动，又能相对及时地清理死连接。

5. 避坑指南：网络对战平台最容易翻车的 6 个真实问题

5.1 粘包半包：服务端收到的消息断成两截或多条黏在一起

现象：服务端日志里出现奇怪的截断内容，比如登录消息只收到了username=zhangs，后面的字符跑到了下一条消息里；或者一条聊天消息后紧跟着半条登录消息，直接解析报错。

原因：TCP 是字节流协议，没有消息边界。客户端连续发送两条消息时，底层可能把两次 write 的数据合并成一次发送；服务端读取时，缓冲区大小也可能把一条完整消息截成两部分。这不是概率问题，是流协议的本质，只要不发协议一定会遇到。

解决：按第 2 章设计固定报文头，接收方先用 readFully 读满 8 字节头部，解析出消息体长度，再按这个长度精确读取消息体。特别注意 readFully 和 read 的区别，前者保证读满指定长度才返回，后者读到多少算多少。这个设计要提前做，不要等出了 bug 再补。

5.2 客户端关窗口，服务端的人还「在线」

现象：某同学在操作界面直接关掉客户端窗口，服务端在线列表里这个人还在，大厅广播里也能看到，但给他发消息没有任何响应。过几分钟之后才掉线。

原因：正常关闭窗口会触发 TCP FIN，服务端能感知；但直接杀进程、断电或者网络断掉，服务端不会收到任何通知，read 一直阻塞在那里，这条连接看起来还活着。

解决：心跳机制必须做。客户端定时发心跳，服务端设置 SoTimeout，超过阈值没收到任何数据就主动断开并清理该用户占用的所有资源。清理动作要放在 finally 里，确保线程异常退出时也能执行。这条不做，演示时一旦有客户端异常退出，大厅就会积累一堆幽灵用户。

5.3 登录后偶发空指针：在线用户表用了 HashMap

现象：登录成功后创建房间，偶尔抛 NullPointerException 或者 ClassCastException，重登之后又正常了，过一会儿又复现，毫无规律。

原因：在线用户表用了普通 HashMap，多个客户端连接线程同时执行 put 和 remove，导致内部数据结构损坏，读出来的对象不是预期的类型。这个问题时好时坏，和系统负载强相关，是典型的多线程并发问题。

解决：所有被多线程共享的集合类，统一换成 ConcurrentHashMap。在线用户表、房间表、匹配队列，一个都不能用普通 HashMap。另外注意，ConcurrentHashMap 只保证单个方法的线程安全，复合操作（比如「先查再删」）仍然要自己加锁或使用原子方法。

5.4 局域网联调连不上：服务端绑定了 127.0.0.1

现象：在自己电脑上运行服务端和客户端一切正常，换成局域网里另一台电脑连接时，要么连接超时，要么直接 Connection refused，但代码明明没改。

原因：服务端初始化时写了new ServerSocket(port)，这在某些平台下默认只监听 IPv6 或回环地址；或明写new ServerSocket(port, 50, InetAddress.getByName("127.0.0.1"))，那就只监听本机回环，局域网里的机器当然连不上。

解决：服务端监听地址统一用 0.0.0.0，表示监听本机所有网卡。另外 Windows 防火墙默认拦截入站连接，需要手动放行服务端端口。这两个问题在毕设答辩现场特别容易踩中，建议提前在演示用的两台电脑上都测一遍，不要只在本机验证。

5.5 聊天内容乱码丢字：编码不一致和长度截取错误

现象：客户端发「你好，准备开始」，对方收到变成「你好��ʼ」或者中间丢字，英文和数字正常，中文不行。

原因：有两种可能。一是两端默认编码不一致：客户端用 UTF-8，服务端用了 Windows 平台的 GBK，中文就乱码；二是服务端读取消息体时没有按协议头里的长度截取，而是直接读了整个缓冲区剩余的数据，把多条消息混在一起。

解决：消息体统一用 UTF-8 编码，发送时str.getBytes(StandardCharsets.UTF_8)，接收时new String(bytes, StandardCharsets.UTF_8)。长度解析严格按协议头来，禁用任何依赖「读到换行符为止」的读取方式。编码问题一旦出现，先看两端代码里的 charset 设置，不要上来就怀疑是 Socket 的问题。

5.6 跑一会儿登录卡死：数据库连接泄漏

现象：系统刚启动时一切正常，运行半小时后登录请求明显变慢，再过一会儿数据库直接报连接数超限，整个平台不可用。

原因：获取数据库连接后没有正确关闭。每个登录请求都创建一个连接，用完不还，连接池或 MySQL 的最大连接数很快被打满。日志里通常能看到Too many connections之类的报错。

解决：数据库操作要遵循「谁打开谁关闭」原则，connect、操作、close 放在同一个方法里，close 必须写进 finally。处理结果的顺序是 ResultSet 先关、PreparedStatement 再关、Connection 最后关。进阶一点可以直接引入 HikariCP 连接池，把连接交给池管理，但我还是建议先学会手动关闭，理解原理后再用池子。

6. 进阶：从「能玩」到「能答辩」——验证清单与两个值得做的优化

项目功能跑通之后，离「可以拿去答辩」还差一步：系统性地验证一遍。这是我每做一个网络项目都会执行的清单，照着走一遍，能在演示前把八成以上的低级问题暴露出来。

第一个值得做的优化是把线程模型从「每连接一线程」升级为事件驱动。用 NIO 的 Selector 统一管理所有连接，一个线程就能处理几百个连接的读写事件。代码量会增加不少，但回报也直接：服务端从几十个连接扩展到几百个不费劲，而且这个对比可以写进论文的测试章节，用数据说明架构升级的必要性。我一般不会把完整 NIO 代码写进正文，放到论文附录或者开源说明里就够。

第二个优化方向是对战同步机制。回合制游戏用状态同步够用，但如果你想让平台的演示效果更出彩，可以尝试帧同步思路：对战双方按固定时间片（比如每 100 毫秒）交换自己本帧的操作，服务端只负责转发和最终裁决。帧同步的优势是在弱网环境下双方看到的过程一致，重放和回放功能也好做，因为整场对局就是一条可回放的指令流。这个设计写到论文的「关键技术」章节，答辩时绝对能拿到加分。

我对这类毕业设计有个坚持的习惯：无论时间多紧，都要先把协议字段定义写死在纸上，再动手写代码。协议是网络对战平台的主动脉，它一旦定错了，后面所有代码都要跟着返工。哪怕最后交付的代码很朴素，只要协议清晰、流程完整、可演示、可验证，这组出题的目的就达成了。希望这篇笔记能帮你把这个题目做成一个「说得清原理、扛得住追问」的毕业设计。

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