WebSocket是浏览器原生支持的基于TCP的全双工通信协议，需正确使用构造函数、处理生命周期、安全收发消息、避免轮询替代，并设计心跳与降级机制。

WebSocket 不是“用 JavaScript 实现”的通信协议，而是浏览器原生支持的、基于 TCP 的全双工通信通道；你不需要自己实现协议，只需要正确使用 WebSocket 构造函数并处理好连接生命周期。

如何创建并维持一个可用的 WebSocket 连接

关键不是“连上”，而是连上后能收发、断开后能重连、出错时有降级感知。直接 new WebSocket 很容易忽略服务端地址有效性、HTTPS 混合内容限制、或未监听 onerror 导致静默失败。

• 必须用 wss://（而非 ws://）接入 HTTPS 页面，否则 Chrome/Firefox 会直接拒绝连接
• 不要在 onopen 回调里立即发消息——确保 readyState === WebSocket.OPEN，有些服务端握手稍慢
• 显式监听 onclose 并做重连判断：若 event.code 是 1006（abnormal closure）或 1001（going away），大概率需重试；1000（normal closure）则不应自动重连
• 用 setTimeout + 指数退避（如 1s → 2s → 4s）控制重连节奏，避免雪崩请求

如何安全地发送与解析消息

WebSocket 传输的是原始字节流，send() 只接受 String、ArrayBuffer、Blob 或 TypedArray；传 JSON 字符串最常用，但必须自己 JSON.stringify() 和 JSON.parse()，且要包裹 try/catch —— 后端发来格式错误的 JSON 会导致前端 onmessage 报错中断。

• 发送前检查 socket.readyState === WebSocket.OPEN，否则会抛 InvalidStateError
• 接收消息时用 if (typeof event.data === 'string') 判断类型，避免 ArrayBuffer 被误当字符串解析
• 对敏感操作（如支付确认）建议加简单校验字段，例如 {type: 'order_confirmed', seq: 123, sig: 'hmac-sha256...'}，不依赖 WebSocket 自身加密（它本身不加密，靠 TLS 层）

为什么用 fetch 或轮询替代不了 WebSocket

HTTP 轮询（哪怕用 fetch）本质是请求-响应模型，每次通信都要建立 TCP 连接、发送 HTTP 头、等待服务端生成响应；而 WebSocket 连接建立后，双方可随时发帧，延迟低、开销小。真实场景下，轮询 1s 一次已造成大量空响应和连接抖动，3s 以上又明显卡顿。

• fetch 无法服务端主动推送数据，所有“实时”都是客户端猜时间去问
• 长轮询（long polling）虽减少连接次数，但每次响应后仍需重建连接，且服务端需维持大量挂起请求，扩展性差
• Server-Sent Events（SSE）单向下行可用，但不支持客户端主动发指令，也无法复用连接做二进制传输

真正难的不是写通 new WebSocket(url)，而是设计心跳机制（服务端定期发 ping 帧，客户端回 pong）、处理代

理/CDN 对 WebSocket 升级头（Upgrade: websocket）的截断、以及在 PWA 离线时优雅降级为本地缓存+重放队列。这些细节不写进业务逻辑，上线后就会在弱网或后台标签页里暴露。