简介这是一套基于WebSocket的实时在线聊天系统完整项目源码面向高校毕业设计、课程设计及期末大作业场景。项目采用Vue.js构建前端界面Node.js搭建后端服务通过WebSocket实现全双工持久通信涵盖用户认证、消息收发、数据加密等关键环节适合需要完整可运行工程参考的开发者。压缩包共31个文件以15个JavaScript脚本、2个Vue组件、2个Styl样式及JSON配置、HTML入口、说明文档等为主类型覆盖前端页面、后端服务、构建工具与项目配置整体仅134KB结构清晰便于按模块分析。已有27人浏览学习。通过该工程可深入理解聊天系统前后端交互流程掌握Vue组件化开发、Node.js非阻塞I/O及WebSocket协议落地方法并可直接基于工程骨架二次开发。1. 基于WebSocket的实时在线聊天系统设计答辩现场不再被问倒本学期课程设计选了基于WebSocket的实时在线聊天系统答辩时评委大概率会追问一句为什么不用HTTP轮询我替几个学弟复盘这份资源时发现翻车的不是代码跑不起来而是项目能演示、原理讲不透。这套聊天系统资源的落点很清晰完整的工程代码、SQL脚本和课程设计配套文档覆盖用户登录、实时收发、在线状态广播、心跳断线重连这些期末大作业和毕业设计的必查点。适合正在赶课程设计或期末大作业的学生尤其是那种需要在现场演示实时聊天、又不想被协议细节问倒的人。拿到手之后按本文顺序走一遍基本能做到“本地能跑、答辩能讲、问题能答”。2. WebSocket核心机制与聊天系统架构握手、帧类型与数据流先把一件事想明白为什么聊天系统不能靠HTTP轮询硬撑。HTTP是典型的半双工请求-响应模型浏览器发一个请求服务器才有机会回一个响应。要让“对方发消息我立刻看到”最朴素的方案是前端每秒调一次接口问“有没有新消息”服务器压力大、消息延迟高而且每次请求光HTTP头就有几百字节比消息正文还大。WebSocket解决的是这个根本矛盾浏览器先发一次普通HTTP请求服务器返回101状态码之后双方在同一条TCP连接上双向收发文本或二进制帧不再需要构造HTTP头。这条连接一旦建立服务端具备主动推送能力聊天、实时在线状态、消息提醒这类场景才真正有了可靠落点。2.1 为什么聊天不能靠HTTP轮询半双工协议与轮询开销先看一次WebSocket握手浏览器发起的初始请求长这样GET /chat/1001 HTTP/1.1 Host: localhost:8080 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw Sec-WebSocket-Version: 13关键是Upgrade: websocket和Connection: Upgrade这两个头它们告诉服务器这次连接我不打算继续走HTTP语义我要切换协议。服务器校验通过后返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWkSec-WebSocket-Accept是服务器根据请求里的Sec-WebSocket-Key拼接固定GUID后做SHA-1再Base64得到的这个过程用来证明“两边都支持WebSocket协议”。从101响应之后这条TCP连接不再有HTTP消息边界而是被WebSocket帧接管。协议层的核心概念是帧类型opcode。文本帧是0x1二进制帧是0x2关闭帧是0x8Ping是0x9Pong是0xA。聊天系统里绝大多数消息是文本帧心跳用的是Ping/Pong。能分清这几种帧后面排查“连接为什么无故断开”会省很多时间。轮询方案之所以在聊天场景被抛弃除了头开销大还有两个硬伤一是消息到达时间完全取决于轮询间隔间隔设1秒对方消息最多延迟1秒间隔设短服务器和带宽都顶不住。二是服务器无法感知客户端是否还在只能靠连接超时猜这个缺陷在轮询里不明显在长连接里会被无限放大后面章节的心跳机制就是专门补这个洞的。2.2 聊天系统的模块划分与核心数据流实际的课程设计聊天系统可以拆成五个关注点登录认证、连接管理、消息路由、消息存储、在线状态广播。登录认证负责把HTTP会话换成userId连接管理器维护当前所有存活WebSocket连接消息路由决定一条消息是私聊、群聊还是系统广播消息存储把聊天记录落库在线状态广播让所有在线端感知“谁上线了、谁掉线了”。我建议按这个顺序读源码先找ServerEndpoint注解标注的类这是所有WebSocket请求的入口再看前端new WebSocket()的地址和它是否对得上最后看数据库脚本里的消息表。课程设计评阅老师一般也按这个顺序看代码代码目录干净、职责清晰印象分会高不少。消息表设计是整个系统的地基这份资源里的表结构大致如下表名关键字段作用t_useruser_id、username、password_hash、avatar用户基本信息t_frienduser_id、friend_id、status好友关系t_messagefrom_user_id、to_user_id、content、message_type、is_read、create_time聊天记录落库其中t_message是全系统核心message_type建议用0表示私聊、1表示群聊to_user_id在群聊场景下可以为NULL靠message_type区分查询时有idx_from_to联合索引即可课程设计阶段没必要上复杂的分库分表。前端与后端约定的消息格式是统一JSON结构后端代码里所有广播逻辑都依赖这个结构{ type: chat, from: 1001, to: 1002, content: 你好我看到你的消息了, timestamp: 1710000000000 }type字段是消息的路由开关我的习惯是取值只有四类login上线、chat聊天、ping/pong心跳、online/offline在线状态广播。这个设计在课程设计文档里也很好写消息类型枚举清晰路由逻辑单一前后端协议一目了然。3. 跑通聊天系统完整流程建库、后端接入、前端联调三连无论资源包里放的是源码压缩包还是课程设计文档第一步永远是先把项目在本地跑起来。很多人的做法是双击打开前端HTML就开始点结果WebSocket连不上一查才发现数据库都没导。我习惯的顺序是先建库再起后端最后开页面。这套资源里的后端工程常见做法是Spring Boot MyBatis-Plus前端是原生JavaScript没有引入Vue或React。原生JS对课程设计演示其实更稳不依赖node_modules项目树简洁答辩时老师问起来也容易解释。3.1 工程初始化与数据库准备目录结构和SQL脚本分工解压后先看目录大致结构如下路径说明backend/src/main/java/com/example/chatSpring Boot后端源码backend/src/main/resources/application.yml端口、数据库连接配置frontend/login.html登录页frontend/index.html聊天主页面frontend/chat.jsWebSocket连接与消息渲染逻辑sql/chat.sql建库建表脚本先执行SQL脚本我处理课程设计项目时习惯先删掉旧库再重建避免脏数据干扰。核心建表语句如下CREATE DATABASE IF NOT EXISTS chat_system DEFAULT CHARACTER SET utf8mb4; USE chat_system; CREATE TABLE t_user ( user_id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, avatar VARCHAR(255), last_login_time DATETIME ) ENGINEInnoDB COMMENT用户表; CREATE TABLE t_friend ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, friend_id BIGINT NOT NULL, status TINYINT DEFAULT 0, UNIQUE KEY uk_user_friend (user_id, friend_id) ) ENGINEInnoDB COMMENT好友关系表; CREATE TABLE t_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, from_user_id BIGINT NOT NULL, to_user_id BIGINT, content TEXT, message_type TINYINT DEFAULT 0 COMMENT 0私聊 1群聊, is_read TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_from_to (from_user_id, to_user_id) ) ENGINEInnoDB COMMENT聊天消息表;这里有个细节值得留意所有表的默认字符集我建议强制指定utf8mb4而不是依赖MySQL全局配置。原因很简单MySQL 8以下版本默认字符集可能是latin1WebSocket文本帧本身是UTF-8一旦表字符集不对消息落库后中文直接变问号而且这种问题只在“发中文”时暴露容易让新手误以为是WebSocket编码问题实际上锅在数据库。t_message表单独对from_user_id和to_user_id建联合索引是因为课程设计文档里的“聊天记录查询”通常要写“按用户和时间倒序分页”这个功能没索引也能跑但加了索引之后实现历史消息页的SQL写起来更干净。数据库连好之后修改后端配置文件application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/chat_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ssserverTimezoneAsia/Shanghai必须加否则高版本MySQL驱动会在时间字段上报时区错误。如果你本机密码不是123456改成自己的即可端口建议固定8080因为前端chat.js里连接的地址是基于当前域名拼出来的改动端口要前后端一起同步。3.2 后端WebSocket接入点基于Spring Boot的端点和会话管理Spring Boot接入WebSocket有两条路一条是WebSocketHandler WebSocketConfigurer另一条是ServerEndpoint。课程设计资源里绝大多数用后者因为它把每个连接的对象化做得更直观很方便在注解方法里写业务逻辑。先看配置类这个类极容易被漏掉漏掉的结果是前端永远连不上package com.example.chat.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.socket.server.standard.ServerEndpointExporter; Configuration public class WebSocketConfig { Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); } }ServerEndpointExporter的作用是把所有带ServerEndpoint注解的类注册进WebSocket容器。没有它Spring Boot不会自动去扫描WebSocket端点前端访问ws://localhost:8080/chat/1001会直接404。这是最常见的“资源拿到手跑不起来”的原因不是代码错是配置类缺失。然后是核心的WebSocket端点类package com.example.chat.websocket; import com.alibaba.fastjson.JSONObject; import org.springframework.stereotype.Component; import jakarta.websocket.*; import jakarta.websocket.server.PathParam; import jakarta.websocket.server.ServerEndpoint; import java.io.IOException; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; Component ServerEndpoint(/chat/{userId}) public class ChatWebSocket { private static final MapString, ChatWebSocket clients new ConcurrentHashMap(); private Session session; private String userId; private long lastHeartbeat System.currentTimeMillis(); OnOpen public void onOpen(Session session, PathParam(userId) String userId) throws IOException { this.session session; this.userId userId; clients.put(userId, this); sendToAll({\type\:\online\,\userId\:\ userId \}); System.out.println(连接建立 userId 当前在线人数 clients.size()); } OnMessage public void onMessage(String text) throws IOException { JSONObject payload JSONObject.parseObject(text); this.lastHeartbeat System.currentTimeMillis(); String type payload.getString(type); if (ping.equals(type)) { // 心跳包只回pong不广播 session.getBasicRemote().sendText({\type\:\pong\}); return; } String to payload.getString(to); if (to ! null !to.isEmpty()) { // 私聊查目标用户连接并定向发送 ChatWebSocket target clients.get(to); if (target ! null) { target.session.getBasicRemote().sendText(text); } } else { // 群聊广播给所有人 sendToAll(text); } } OnClose public void onClose() { clients.remove(userId); sendToAll({\type\:\offline\,\userId\:\ userId \}); } OnError public void onError(Throwable t) { clients.remove(userId); } private void sendToAll(String message) { for (ChatWebSocket client : clients.values()) { if (client.session.isOpen()) { try { client.session.getBasicRemote().sendText(message); } catch (IOException e) { clients.remove(client.userId); } } } } }这里有两个选型细节值得背下来。第一用ConcurrentHashMap而不是CopyOnWriteArraySet来存连接因为聊天系统里“按userId定向发消息”是高频操作Map的随机访问是O(1)而Set要遍历才能找到目标。第二onError里同样要移出连接因为浏览器直接断电或刷新时onClose不一定能触发只靠onClose清理会话会留下大量僵尸连接。lastHeartbeat字段是给第四章心跳检测用的先埋在这里收到任何一条消息都刷新它包括业务消息和Ping包。这样服务端判断“客户端是否存活”时不需要额外的心跳计数器直接看这个时间戳距离当前时间多久即可。3.3 前端连接与消息渲染登录后建立连接并动态更新聊天窗口前端我用原生JavaScript写核心逻辑集中在chat.js里。用户登录成功后把userId存进sessionStorage然后创建WebSocket连接// chat.js 核心连接逻辑 const userId sessionStorage.getItem(userId) || 1001; const ws new WebSocket(ws:// window.location.host /chat/ userId); ws.onopen function () { console.log(WebSocket open, userId , userId); // 上线后广播自己的在线状态 ws.send(JSON.stringify({ type: login, userId: userId })); }; ws.onmessage function (event) { let msg; try { msg JSON.parse(event.data); } catch (e) { console.warn(收到非JSON消息, event.data); return; } if (msg.type chat) { appendMessage(msg.from, msg.content); } else if (msg.type online || msg.type offline) { refreshOnlineUser(msg.userId, msg.type online); } }; ws.onerror function (err) { console.error(WebSocket error, err); }; // 把消息追加到聊天窗口 function appendMessage(from, content) { const list document.getElementById(messageList); const node document.createElement(div); node.textContent from content; list.appendChild(node); list.scrollTop list.scrollHeight; }这里有一个平时上课不会强调、但课程设计里一定会被问到的点ws.onmessage里收到的event.data到底是什么类型。如果你的后端发的是文本帧只要不在前端改动ws.binaryType这里拿到的就是一个字符串可以直接JSON.parse。一旦你加了ws.binaryType blob或者后端发了二进制帧event.data会变成一个Blob对象此时直接解析会抛语法错误必须先用FileReader.readAsText(blob, UTF-8)转成字符串再解析。跑通这三步后你已经能实现“打开两个浏览器窗口互相发消息”的演示效果。这一步是整个课程设计的地基因为后面所有的状态广播、心跳机制、重连逻辑都在这个基础上叠加。4. 心跳机制与断线重连把“假在线”和“静默掉线”一起填平聊天系统跑通只是起点。课程设计答辩最喜欢问的一个隐藏问题就是客户端断网了服务端怎么知道这个问题的标准答案是用心跳机制。WebSocket长连接最难受的地方不是网络差而是网络断了但TCP连接还悬在那里服务端完全无感知。我在帮人排查这类问题时最常看到的场景是现场演示说“对方在线”其实对方早拔网线走了消息发过去毫无反应全程黑匣子状态。4.1 为什么服务端必须主动探测心跳TCP假死与NAT超时TCP协议本身只保证可靠传输不保证“连接一定活着”。当客户端断网、休眠、切换Wi-Fi时TCP层可能收不到任何FIN或RST包服务端会一直认为这条连接还活着这个现象叫TCP假死。更隐蔽的是家用路由器、运营商NAT设备通常会在60到120秒没有流量时回收端口映射连接从中间被切掉双方都感知不到。聊天系统里的在线状态依赖服务端维持一个可靠连接集合。如果连接假死最直接的后果是“在线列表与实际不符”。要解决这个问题必须让客户端定期发出心跳证明自己活着服务端记录每个连接的最后心跳时间超过阈值就判定死亡并强制清理。这是教科书里不会细写、但实际工程里必须做的部分。心跳的设计有两个关键参数发送间隔和超时阈值。间隔太长会让“假在线”状态持续很久间隔太短又浪费带宽。我一般用下面这组参数课程设计场景完全够用参数建议值理由心跳发送间隔25秒低于NAT设备60秒超时又不会太频繁服务端超时阈值60秒容忍1次心跳丢失避免公网抖动误杀心跳扫描周期10秒最多让僵尸连接存活70秒重连最大延迟30秒防止服务端故障恢复后瞬间被重连打崩4.2 心跳代码实现前端定时器与后端超时判定前端在连接建立后启动一个定时器每25秒发一次Ping// 心跳定时器每25秒发一次ping证明连接活着 function startHeartbeat() { if (window.heartbeatTimer) { clearInterval(window.heartbeatTimer); } window.heartbeatTimer setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: ping, ts: Date.now() })); } }, 25 * 1000); }注意发送前必须判断ws.readyState WebSocket.OPEN否则在连接正在关闭的过程中调用send方法浏览器会抛InvalidStateError。我在第一次写心跳时就踩过这个坑定时器回调比连接关闭晚触发了几毫秒控制台直接报错。后端的超时判定不能放在onMessage里做因为僵尸连接根本不会发消息过来。正确做法是用Spring的Scheduled定时任务每10秒扫描一遍所有连接package com.example.chat.task; import com.example.chat.websocket.ChatWebSocket; import org.springframework.scheduling.annotation.Scheduled; import org.springframework.stereotype.Component; Component public class HeartbeatTask { Scheduled(fixedDelay 10 * 1000) public void scanDeadConnections() { long now System.currentTimeMillis(); for (ChatWebSocket client : ChatWebSocket.getAllClients()) { // 超过60秒没有心跳判定连接死亡 if (now - client.getLastHeartbeat() 60 * 1000) { System.out.println(心跳超时清理连接 client.getUserId()); client.close(); } } } }这里fixedDelay的含义是上一次任务执行完成后间隔10秒再执行下一次。如果改成fixedRate则是从任务开始计时任务执行时间过长时可能出现并发重入。扫描任务本身很轻量几毫秒内完成用fixedDelay更合适。同时要在启动类上加EnableSchedulingSpringBootApplication EnableScheduling public class ChatApplication { public static void main(String[] args) { SpringApplication.run(ChatApplication.class, args); } }忘了加这个注解是常见翻车点之一症状是心跳扫描任务完全不执行服务端永远不清理过期连接。ChatWebSocket里需要补三个方法getAllClients()返回连接集合getUserId()返回用户标识close()关闭连接并从集合移除。我一般把close()做成幂等方法多次调用不会报错因为心跳扫描和onError可能同时触发清理public void close() { clients.remove(userId); try { if (session.isOpen()) { session.close(); } } catch (IOException e) { // 清理阶段忽略关闭异常 } }4.3 断线重连与指数退避防止重连风暴只有心跳没有重连聊天体验仍然很粗糙。Wi-Fi闪断30秒再恢复心跳会把死连接清理掉但如果前端不做重连用户只能刷新页面。我习惯在onclose事件里触发重连并且用指数退避控制重连频率let reconnectAttempts 0; function connect() { const wsUrl ws:// window.location.host /chat/ userId; const socket new WebSocket(wsUrl); socket.onopen function () { reconnectAttempts 0; console.log(连接成功); }; socket.onclose function (event) { // 指数退避1秒、2秒、4秒……最大30秒 const delay Math.min(1000 * Math.pow(2, reconnectAttempts), 30000); reconnectAttempts; console.log(连接关闭code event.code delay ms 后重连); setTimeout(connect, delay); }; socket.onmessage function (event) { handleMessage(event.data); }; ws socket; } connect();这里Math.pow(2, reconnectAttempts)会产生序列1秒、2秒、4秒、8秒、16秒、32秒封顶到30秒。这么做的好处是服务端重启后所有客户端不会在同一秒齐刷刷地重连而是错峰恢复。如果不用指数退避两千个客户端同时断线后同时重连服务端很可能直接被自己的心跳扫描和重连请求打崩。重连成功后需要重新发一次login消息让其他在线端知道“我又上线了”。这个细节很多人会漏结果就是断线重连后自己能看到对方消息但对方的在线列表里自己仍是灰色。我通常在onopen里统一处理登录广播无论首次连接还是重连都走同一套逻辑socket.onopen function () { reconnectAttempts 0; socket.send(JSON.stringify({ type: login, userId: userId })); };断线重连还有一个值得写进课程设计文档的点关闭码。event.code为1000表示正常关闭1006表示非正常关闭TCP连接异常中断4010/4011是服务端拒绝连接。如果答辩时能说出“通过关闭码区分主动关闭和异常掉线”评委印象分会明显提升。5. 聊天系统的常见问题与避坑五个高发故障的现场还原WebSocket聊天系统的坑绝大多数集中在“连接生命周期管理”上。我复盘过不少课程设计项目代码结构大差不差真正让项目翻车的往往是一些小细节。这一章把最高频的五个问题整理成排查记录每条都按“现象 → 原因 → 解决”的顺序写方便你直接对照自己的项目。5.1 先按这三步定位问题前端、后端、网络三层各看什么遇到问题不要急着改代码先按固定顺序排查。第一步打开浏览器开发者工具看Console面板有没有红色报错再切到Network面板找到WS类型的请求看状态码是否停在101。如果Network里根本没有WS请求说明前端代码压根没执行到new WebSocket。第二步看后端控制台日志。Spring Boot的WebSocket在连接建立时会打印日志能定位到具体用户异常堆栈里如果出现EOFException或Connection reset基本是前端异常断开导致的清理问题。第三步才是查代码逻辑重点看ServerEndpoint路径与前端连接地址是否一致以及操作系统的防火墙是否放行了8080端口。这三步能覆盖90%的“连不上”问题剩下10%是配置与网络环境问题再往下翻坑。5.2 五个高发坑现象、原因、解决坑1前端一直报404WebSocket握手失败现象浏览器控制台显示WebSocket connection to ws://localhost:8080/chat/1001 failed: Error during WebSocket handshake: Unexpected response code: 404。原因最常见的是路径不一致。前端连接地址是/chat/1001但后端ServerEndpoint注解写的是/chat/{userId}这两者本身是匹配的真正的坑是漏了ServerEndpointExporter配置类导致Spring Boot根本不知道这个端点存在。另一个常见原因是端口不一致后端跑在8081前端连的还是8080。解决先确认WebSocketConfig里的ServerEndpointExporter已注册再把前端URL改成ws:// window.location.host /chat/ userId让前端自动跟随当前页面域名和端口彻底杜绝硬编码端口导致的失配。坑2自己发的消息自己能看到其他端收不到现象打开两个浏览器窗口A窗口发消息A窗口自己正常显示B窗口毫无反应但B窗口的状态显示在线。原因后端onMessage里把消息直接通过session.getBasicRemote().sendText()发回给了发送者自己的session而没有遍历clients集合广播给其他连接。这是初学WebSocket时最容易犯的逻辑错以为连接对象session代表所有连接实际上每个session只代表一条连接。解决私聊消息用clients.get(to)定向发送群聊消息调用sendToAll(text)遍历整个连接集合。注意遍历时如果是普通HashMap一边遍历一边删除会抛ConcurrentModificationException必须用ConcurrentHashMap。坑3页面一刷新后端就报EOFException现象按F5刷新页面后端控制台刷出EOFException、Remote host closed connection during handshake有时还会伴随连接未清理的告警。原因浏览器刷新页面时会直接断开TCP连接但WebSocket的onClose回调此时不一定会被触发。尤其当后端还没收到Close帧、TCP就先被操作系统断开时后端只能在下一次往这个session写数据时才感知到连接已死此时抛出EOFException。解决双管齐下。后端在OnError里做同样的连接移除逻辑前端在beforeunload事件里主动发送关闭帧window.addEventListener(beforeunload, function () { if (ws ws.readyState WebSocket.OPEN) { ws.close(1000, page refresh); } });加上这个前置关闭后刷新页面时后端能收到正常的1000关闭码onClose稳定触发EOFException基本绝迹。坑4服务端在线列表显示在线但发消息无人响应现象系统运行一段时间后在线列表里某个用户头像还是亮的但给他发消息没有任何反馈重启后端后该用户又恢复在线。原因这是典型的僵尸连接。客户端断网或休眠TCP连接既没收到FIN也没收到RST服务端完全不知情一直把这条连接留在内存里。如果你没做心跳机制这个问题会在实际使用中随机出现且极难复现属于典型的“黑匣子问题”。解决把第四章的心跳机制完整加上。客户端25秒发一次Ping服务端60秒收不到就主动清理连接并广播offline。加了心跳后在线列表的准确性会有质的提升答辩现场如果评委问“断网后你怎么处理”直接演示这个清理流程最有力。坑5中文消息显示乱码英文正常现象发送“你好”对方页面显示“浣犲ソ”或“鏄浠”这类乱码控制台看到的消息内容却是正常的。原因WebSocket文本帧在协议层强制UTF-8编码但前端收到消息后如果走了二进制处理通道比如设置了binaryType blob然后在onmessage里用readAsBinaryString读取二进制会被按单字节映射成Latin-1字符中文自然变成乱码。解决前端统一走文本帧解析不设置binaryType直接JSON.parse(event.data)如果确实需要Blob处理用FileReader.readAsText(blob, UTF-8)明确指定编码。后端发送消息时不要对字符串做任何额外编码转换JSON序列化默认UTF-8即可。6. 演示前的验证技巧在DevTools里盯住心跳与帧到了准备答辩演示这一步我会额外花十分钟做三件看起来不起眼、实际上能救场的事。第一件事是打开Chrome开发者工具的Network面板找到WS类型的连接点进去看Messages子页签确认Ping和Pong帧在持续交替出现。如果你看到了稳定的25秒间隔的Ping/Pong说明心跳机制工作正常这一眼比看十页代码都管用。第二件事是用过滤功能验证消息帧类型。DevTools的Messages子页签上方有个过滤框输入Ping可以只看心跳请求输入Pong看响应。更精细的验证是抓包Wireshark里先选中本地回环网卡然后用过滤表达式websocket.opcode 0x9 || websocket.opcode 0xA这个表达式的意思是只看Ping和Pong控制帧。如果能看到成对的0x9和0xA交替出现就说明心跳协议从应用层到TCP层完全打通这个证据在课程设计报告里写一句“通过抓包验证了心跳帧的收发”比截图代码更有说服力。第三件事是人为制造一次掉线验证清理逻辑是否兜得住。在DevTools里切换到Network面板把网卡状态改为Offline后等60秒再切回Online。此时观察后端日志60秒后应该有“心跳超时清理连接”的输出同时前端会按指数退避自动重连重连成功后自动发login广播。整个过程不需要刷新页面在线列表会自动恢复为“在线”状态。我第一次做课程设计演示时现场Wi-Fi信号不稳有台测试机的连接静默掉线页面还显示“在线”被答辩老师当场问住了。从那以后我每次演示前都会强制走一遍“看心跳、查帧、模拟断网”三连检查确认整套机制是真的在跑而不是碰巧没出问题。这个小习惯帮我避开了多次现场翻车也让我对那些“能跑但说不清”的项目多了几分警惕。希望帮到你。本文还有配套的精品资源点击获取