WebSocket实现全双工持久化TCP连接，低延迟毫秒级；长轮询基于HTTP伪实时，有头部开销、空窗期和高资源消耗。选型依场景：高频低延用WebSocket，兼容旧环境或低频同步用长轮询。
JavaScript 实现实时通信主要靠 WebSocket，它建立的是浏览器与服务器之间的**全双工、持久化 TCP 连接**，消息可随时双向收发；而 长轮询（Long Polling） 是一种“伪实时”方案，本质仍是 HTTP 请求-响应模型，靠反复发起请求来模拟实时性。两者核心区别不在代码写法，而在通信机制和性能表现。
WebSocket：一次连接，持续通信
WebSocket 在首次握手时通过 HTTP 升级（Upgrade: websocket）切换协议，之后完全脱离 HTTP，使用独立帧格式传输数据。客户端用 new WebSocket(url) 创建连接，监听 onmessage 接收消息，调用 send() 发送消息。
- 连接建立后无请求头开销，消息轻量（最小仅2字节帧头）
- 服务端可主动推送，延迟通常在毫秒级
- 需服务端支持 WebSocket 协议（如 Node.js 的
ws库、Nginx 配置 proxy_pass + Upgrade 头） - 不兼容老旧环境（IE9 及以下不支持），但现代浏览器全覆盖
长轮询：HTTP 的“等待式”妥协
客户端发一个 GET 请求，服务端不立即响应，而是挂起请求，直到有新数据或超时（如30秒）才返回。客户端收到响应后，立刻发下一个请求，形成“请求→等待→响应→再请求”的循环。
- 所有通信走标准 HTTP，天然兼容代理、CDN 和旧浏览器
- 每次请求都有完整 HTTP 头部（至少几百字节），频繁建立连接带来额外开销
- 存在“空窗期”——上一个响应结束到下一个请求发出之间，可能错过消息
- 服务端需维护连接等待队列，高并发下资源消耗比 WebSocket 显著更高
怎么选？看场景，不看技术偏好
若项目要求低延迟、高频交互（如在线协作文档、实时游戏、交易看板），优先用 WebSocket；若需支持 IE8/9、内网老旧网关，或只是偶尔同步状态（如通知红点、订单状态变更），长轮询更稳妥。实际开发中，可用 Socket.IO 这类库自动降级：先尝试 WebSocket，失败则 fallback 到长轮询，开发者只需写一套接口。
立即学习“Java免费学习笔记（深入）”；
简单对比：一次消息往返的差异
假设发送一条“hello”：
- WebSocket：客户端 send("hello") → 服务端 onmessage 触发 → 服务端 send("world") → 客户端 onmessage 触发。全程无新连接、无头部、无解析开销。
- 长轮询：客户端发请求 A → 服务端延迟响应 A → 客户端解析 A 得到 "hello" → 立即发请求 B → 服务端响应 B 带 "world" → 客户端解析 B。两次完整 HTTP 往返，至少 4 次 TCP 握手（若未复用连接）。
不复杂但容易忽略：WebSocket 连接需要正确处理断线重连、心跳保活和错误降级；长轮询则要注意服务端超时设置与客户端请求节奏匹配，避免雪崩。选对方案只是开始，健壮性才是实时通信的关键。
