WebSocket适合实时通信因其双向低延迟、省带宽、状态可控；HTTP为文档获取设计，单向且高开销；使用需注意兼容性、代理拦截、服务端成本及手动实现重连等。
WebSocket 在 JavaScript 中用起来很直接，但关键在于理解它和 HTTP 的本质差异——不是“怎么写代码”，而是“什么时候该换通信方式”。它解决的不是功能问题，而是实时性、资源消耗和交互模型的问题。
WebSocket 基础用法（三步走）
创建连接、监听事件、发送数据，三步就能跑通：
-
建立连接：用
new WebSocket(url, protocols)，url 是ws://或加密的wss://，protocols 可选（比如'chat'），用于服务端协商子协议。 -
监听核心事件：
-
onopen：握手成功，可开始发消息； -
onmessage：收到服务器推送的数据，event.data是字符串或 ArrayBuffer； -
onclose：连接关闭，event.code和event.reason可查原因； -
onerror：出错时触发（注意：它不提供具体错误信息，需结合日志或网络面板排查）。
-
-
发送与关闭：
- 发送文本：直接
socket.send('hello')；复杂结构先JSON.stringify()； - 发送二进制：用
ArrayBuffer或Blob； - 主动断开：
socket.close(code, reason)，code 一般用 1000（正常关闭）。
- 发送文本：直接
WebSocket 为什么更适合实时通信？
它不是“比 HTTP 快一点”，而是彻底改变了通信逻辑：
- 真正双向、低延迟：连接建立后，服务器无需等请求，随时能推数据（如聊天新消息、股价跳动）；HTTP 每次都要客户端发起请求，哪怕只差 100ms，累积起来就是卡顿感。
- 省带宽、减负载：一次握手后复用 TCP 连接，没有 HTTP 头部（几十字节）、无 Cookie、无状态重传；轮询场景下，1 秒一次 HTTP 请求，90% 流量都在传重复头部。
-
连接状态可控：通过
readyState（0=connecting, 1=open, 2=closing, 3=closed）可判断当前是否可发数据；HTTP 每次都是全新连接，状态不可延续。
HTTP 在实时场景下的硬伤
不是 HTTP 不好，而是设计目标不同——它为“文档获取”而生，不是为“持续对话”：
立即学习“Java免费学习笔记（深入）”；
- 单向请求-响应模型：客户端永远是发起方，服务器不能“主动喊你”；想模拟推送只能靠轮询（浪费资源）或长轮询（连接易断、延迟难控）。
- 每次通信都有开销：TCP 三次握手 + TLS 握手（HTTPS）+ HTTP 头部解析，毫秒级延迟在高频更新中会被放大（比如每秒 5 次行情推送，HTTP 就得建 5 次连接）。
-
无原生连接保活机制：HTTP/1.1 虽支持 keep-alive，但超时时间由服务器控制，客户端无法感知断连；WebSocket 有
ping/pong帧保活，且断连后可通过onclose明确捕获并重连。
别忽略的现实约束
用 WebSocket 不等于一劳永逸，有些坑必须提前填：
