WebSocket是实现浏览器端实时聊天室最直接高效的方式，通过持久双向通道替代轮询，实现低延迟、高准确率、低资源消耗的实时通信。
WebSocket 是实现浏览器端实时聊天室最直接、高效的方式。它不是靠反复“问服务器有没有新消息”，而是建立一条持久双向通道，消息来得快、发得准、资源省。
一、前端连接与基础事件监听
在页面 JS 中创建 WebSocket 实例，并绑定关键生命周期事件：
- 用 ws:// 或 wss:// 协议连接后端地址，例如
new WebSocket('wss://your-api.com/chat') - onopen：连接成功后立即触发，适合发送登录标识或初始化请求
-
onmessage：收到服务器推送的消息时触发，
event.data就是原始消息内容（通常为 JSON 字符串） - onerror：连接异常时触发，建议记录日志但不直接弹窗干扰用户
- onclose：连接断开时触发，可在此启动自动重连逻辑（如延迟 3 秒后重试）
二、消息发送与格式规范
发送消息前，确保连接已打开（检查 socket.readyState === 1），再调用 send()：
- 推荐统一使用 JSON 格式，包含必要字段：如
{ "type": "text", "from": "user_abc", "to": "user_xyz", "content": "你好", "timestamp": 1726417520 } - 避免直接 send 原始字符串，否则后端解析困难，也难扩展功能（比如加图片、撤回、已读等）
- 发送失败时，
send()不会抛错，需依赖onerror或服务端 ACK 回执判断是否送达
三、服务端配合要点（Node.js 示例）
仅前端连上还不够，后端必须能维持连接并广播/路由消息。以轻量库 ws 为例：
立即学习“Java免费学习笔记（深入）”；
- 每个客户端连接进来，
wss.on('connection', ws => { ... })中保存该ws实例（如存入 Map 或数组） - 收到消息时，解析 JSON，根据
to字段决定是群发、单发还是存离线——不要无脑broadcast - 主动关闭连接时调用
ws.close()；客户端断开后，及时从存储中移除对应实例，防止内存泄漏 - 建议加心跳机制：
ws.ping()定期探测，超时未响应则清理连接
四、实际开发中容易忽略的细节
很多聊天室跑起来就出问题，往往卡在这些地方：
- 微信小程序里不能用
ws://localhost，必须是合法域名且已配置到后台服务器域名白名单 - 服务端若部署在 Nginx 后，需额外配置
proxy_set_header Upgrade $http_upgrade;等 WebSocket 支持项 - 消息重复渲染？检查是否在
onmessage里多次绑定事件，或未做防抖处理 - 中文乱码？确保前后端都使用 UTF-8 编码，服务端发送前不用额外
encodeURI
