WebSocket 更适合实时双向场景，长轮询是稳妥降级选择；选型取决于运维能力与毫秒级响应需求，持续消息流才显 WebSocket 优势。
websocket 不是“更好”，而是“更适合实时双向场景”；长轮询不是“落后”，而是“更稳妥的降级选择”。选哪个，取决于你有没有能力承担 websocket 的运维复杂度，以及是否真的需要毫秒级响应。
WebSocket 的连接建立和心跳必须自己管
WebSocket 握手成功后，连接不会自动保活。NAT、代理、负载均衡器或防火墙可能在 30–60 秒无数据时静默断连，而 session 对象本身不报错。
- 必须主动发
pings（服务端用session.getAsyncRemote().sendPing()，客户端用ws.send(JSON.stringify({type:"ping"}))） - 客户端需监听
onclose并实现指数退避重连（比如 1s → 2s → 4s → 最大 30s） - Spring Boot +
@ServerEndpoint默认不处理超时，得手动加@OnMessage拦截 ping/pong 或配maxSessionIdleTimeout
长轮询的超时时间不是越长越好
设成 60 秒看似“省请求”，但实际会放大延迟：若服务器在第 59 秒才产生数据，客户端仍要等满 60 秒才收到；下一次请求又从头开始，形成“伪延迟尖峰”。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 生产环境推荐 10–20 秒超时，配合服务端
writeTimeout控制挂起上限 - 务必在响应头中加
Cache-Control: no-cache, no-store, must-revalidate，避免 CDN 或浏览器缓存空响应 - 每次请求需携带唯一
last_event_id或时间戳，防止消息重复或跳过（尤其在重连时）
带宽和连接数差异在千并发时就肉眼可见
按每秒推送一条 100 字节消息估算：
- 1000 个 WebSocket 连接：约占用 1000 个 TCP 连接，带宽 ≈
0.1 KB/s × 1000 = 100 KB/s，内存 ≈4KB × 1000 = 4 MB - 1000 个长轮询客户端（30 秒超时）：每小时新建
120,000次连接，HTTP 头平均 1KB，仅头部流量就达120 MB/h，CPU 花在解析Cookie、Authorization、路由匹配上 - 真实压测中，Node.js + Express 长轮询服务在 3000 并发时 CPU 常飙到 70%+；而
ws库在相同机器上撑满 10,000 连接，CPU 仍低于 20%
真正容易被忽略的点是：WebSocket 的优势只在“持续有消息流”时成立。如果用户平均在线 5 分钟，期间只收 3 条通知，那长轮询反而更轻量——握手开销省了，连接管理逻辑也简单。别为了技术先进性强行上 WebSocket。
