连接异常时需智能降级轮询：综合event.code、连续失败次数及页面可见性判断真实断连；轮询须复用session_id、支持增量拉取并统一消息分发，推荐sockjs或自建transport封装。
连接异常时自动切到轮询，不是简单“失败就发 fetch”，而是要有状态判断、会话延续和消息对齐。核心在于：WebSocket 断开后，前端要识别是临时网络抖动还是彻底不可用，并在降级期间保持数据语义一致。
识别真实断连，避免误降级
不能一看到 onclose 或 onerror 就立刻切轮询——很多情况是正常关闭（如页面刷新）、心跳超时重连中，或短暂闪断。应结合以下信号综合判断：
- 检查
event.code：1000（正常关闭）、1001（服务端下线）不触发降级；1006（异常关闭）、1011（服务器内部错误）或无 code 的 error 事件才考虑切换 - 记录连续失败次数：首次断开先尝试重连（比如 3 秒后
new WebSocket()），连续 2 次重连失败（间隔 ≥5 秒）再启动轮询 - 排除浏览器休眠干扰：监听
visibilitychange，若页面隐藏时断开，唤醒后再检查连接状态，不立即降级
轮询必须复用 WebSocket 的会话上下文
降级不是另起炉灶，而是延续原有逻辑。关键点：
- 带上上次 WebSocket 连接的唯一标识（如服务端下发的
session_id或client_token），让后端知道这是“同一个客户端换通道来了” - 轮询接口需支持增量拉取：例如请求
/api/ws-poll?last_seq=123，后端只返回seq > 123的消息，避免重复或丢失 - 前端维护一个本地
lastReceivedSeq，每次成功收到轮询响应后更新，下次请求自动带上
轮询阶段的消息处理要与 WebSocket 对齐
用户不应感知通信方式变化。要做到：
- 统一消息分发入口：所有数据（无论来自
onmessage还是轮询fetch成功回调）都走同一个handleMessage(data)函数 - 轮询响应体格式尽量模拟 WebSocket 帧：后端返回 JSON 数组
[{"type":"status","data":{...}},{"type":"metric","value":24.5}]，前端遍历触发多次“伪 onmessage” - 当 WebSocket 重新连上，先用
lastReceivedSeq向服务端同步未确认消息，再清空轮询定时器，平滑切回主通道
不要自己实现轮询调度，用 SockJS 或自研轻量适配层
手动写 setInterval(() => fetch(...), 3000) 容易出问题：无法处理请求堆积、响应乱序、服务端消息积压等。推荐两种落地方式：
- 直接集成 SockJS：它内置降级逻辑，
new SockJS(url)后无需改业务代码，底层自动在 WebSocket 失败时切 xhr_polling，并维持 session、消息序号和重连策略 - 自建薄封装层：定义
Transport接口，含connect()、send()、on('message')，WebSocket 和 Polling 实现各自类，由统一管理器按健康度切换
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
