WebSocket如何实现javascript实时通信【教程】_技术教程

WebSocket是浏览器与服务端建立持久双向通道的协议，其“实时性”取决于服务端逻辑、网络稳定性、错误恢复及消息序号处理；需用wss://URL创建实例，校验readyState后
再send，手动实现带退避的重连，并在onmessage中安全解析JSON。

WebSocket 不是“实现”实时通信的方案，而是浏览器与服务端之间建立持久双向通道的协议；用 JavaScript 调用 WebSocket 构造函数就能发起连接，但能否真正“实时”取决于服务端逻辑、网络稳定性、错误恢复策略和消息序列处理是否到位。

如何用 `WebSocket` 构造函数建立连接

直接 new 一个实例是最简起点，但必须传入有效的 ws/wss URL，且不能跨域（除非服务端明确允许）：

const ws = new WebSocket('wss://api.example.com/realtime');

常见错误现象：Failed to construct 'WebSocket': The URL 'http://...' is invalid —— 注意必须是 ws:// 或 wss://，不能写 http://；net::ERR_CONNECTION_REFUSED 表明后端没监听或地址不对；403 Forbidden 多因服务端校验 Origin 或 token 失败。

连接成功后触发 onopen 回调，此时才能调用 send()
连接失败或关闭时，onerror 和 onclose 都可能触发，不要只监听其中一个
若需传递鉴权信息，建议通过 URL query 参数（如 wss://...?token=abc123），而非 header（浏览器不支持自定义握手头）

`send()` 发送数据前必须检查 `readyState`

很多人在页面加载完立刻调用 send()，却忽略连接尚未建立完成，导致静默失败。正确做法是只在 ws.readyState === WebSocket.OPEN 时发送：

if (ws.readyState === WebSocket.OPEN) {
  ws.send(JSON.stringify({ type: 'ping', data: Date.now() }));
} else if (ws.readyState === WebSocket.CONNECTING) {
  // 可选择缓存消息，或等 onopen 后重发
}

readyState 有四个值：CONNECTING(0)、OPEN(1)、CLOSING(2)、CLOSED(3)
不要依赖 setTimeout 等待固定毫秒数来判断连接就绪——网络延迟不可控
二进制数据可直接传 ArrayBuffer 或 Blob，但 JSON 字符串仍需手动 JSON.stringify()

如何避免 `onmessage` 收到乱序或粘包数据

WebSocket 协议本身不保证应用层消息边界，浏览器会把多个 send() 合并为一个帧，或把大消息拆成多个帧；但 onmessage 每次触发都对应一个完整帧（文本或二进制），所以“粘包”问题在浏览器端几乎不存在 —— 真正的风险来自服务端未按帧发送，或前端未正确解析多层嵌套结构。

服务端若用 Node.js 的 ws 库，确保每次 socket.send() 发送的是独立 JSON 字符串，而非流式拼接
前端收到字符串后，应包裹 try/catch 做 JSON.parse()，防止某条异常消息阻塞后续处理
若需严格顺序（如聊天消息 ID 递增），应在消息体中携带序号，并在前端做去重和排序缓冲，不能依赖接收顺序

为什么 `onclose` 触发后无法自动重连

WebSocket 连接断开后不会自动重试，必须手动实现重连逻辑。简单轮询重连容易引发雪崩，合理做法是带退避策略：

let reconnectTimeout = 1000;
function connect() {
  ws = new WebSocket(url);
  ws.onclose = () => {
    setTimeout(() => {
      connect();
      reconnectTimeout = Math.min(reconnectTimeout * 2, 30000);
    }, reconnectTimeout);
  };
}

服务端主动关闭时会传 event.code 和 event.reason，比如 1001（going away）、4000+（自定义业务码），可用于区分是否需要重连
频繁 onerror + onclose 循环可能是服务端证书过期（wss）、反向代理超时（如 Nginx 默认 60s 关闭空闲连接）、或客户端休眠唤醒后 socket 状态未同步
移动端切后台再切回时，部分浏览器会冻结 WebSocket，需监听 visibilitychange 并手动重建连接

真正难的不是打开连接，而是让连接在弱网、切后台、服务重启、DNS 变更等场景下持续可用；多数线上问题出在重连时机判断、消息确认机制缺失、以及对 readyState 的误用上。