WebSocket核心优势是“更省、更稳、更准”：连接开销低（单次握手复用TCP，帧头仅2–6字节）、服务端资源占用少（千用户带宽从800KB/s降至106KB/s，线程/连接池压力大幅下降）、端到端延迟更可控（≈网络传输时间，远低于轮询的间隔依赖）。
WebSocket 在 JS 中相比传统轮询（Polling）的核心性能优势，不是“更快”，而是“更省、更稳、更准”——尤其在中高并发、中低延迟要求的场景下。
连接开销大幅降低
传统轮询每次请求都要走完整 HTTP 生命周期：TCP 握手 → HTTP 请求头（约 800B）→ 服务端处理 → 响应头 + 数据 → TCP 断开。频繁短连接带来显著延迟和资源消耗。
WebSocket 只需一次升级握手（HTTP Upgrade），之后复用同一 TCP 连接，后续每条消息帧头仅 2–6 字节，无重复头部、无连接重建开销。1000 用户每秒收 1 条消息时，带宽节省可达 7 倍以上（约 800KB/s → 106KB/s）。
服务端资源占用明显更少
轮询下，每个请求都需占用一个服务端线程/连接槽位（尤其 Node.js 或 Java 同步模型），大量空闲等待请求极易耗尽连接池或线程数。
WebSocket 单连接可承载全部双向通信，内存与句柄占用稳定。即使 10 万在线用户，也只需维持约 10 万长连接，而非百万级 HTTP 短连接。
端到端延迟更可控且更低
轮询延迟 = 轮询间隔 + 网络 RTT + 服务端处理时间。若设为 2s 间隔，平均延迟就接近 1s；缩到 500ms 又会引发雪崩式请求。
WebSocket 理论端到端延迟≈网络传输时间（局域网
消息时序与状态管理更可靠
轮询天然无法保证顺序：两次请求可能乱序返回，重试逻辑易导致重复或跳过消息。
WebSocket 虽不强制保序（依赖 TCP），但单连接通道+合理序列号设计（如消息体加 timestamp 或 seq 字段），比轮询更容易实现准确的状态同步。配合心跳与自动重连机制，也能更好应对弱网下的连接抖动。
