WebSocket在老旧浏览器中不可用，需设计可切换、状态可控的轮询降级机制：先检测构造函数并试探连接，超时未open即判定失败；按场景选用短轮询（指数退避）或长轮询（服务端超时+消息去重）；统一接口抽象底层差异；监听页面可见性与卸载事件，避免资源泄漏。
WebSocket 在部分老旧浏览器（如 IE9 及更早版本、Android 4.0 WebView、iOS Safari 9 以下）中不可用或存在握手失败问题，不能靠简单报错就终止通信。核心思路不是“补 WebSocket”，而是设计一套可切换、状态可控、资源友好的轮询降级机制，让实时能力不中断。
先准确检测 WebSocket 是否真正可用
仅判断 window.WebSocket 存在不够，IE10+ 声称支持但可能因安全策略或代理拦截导致 new WebSocket(url) 立即报错或静默失败：
- 封装检测函数，既查构造函数，也做连接试探：先创建实例，监听
onerror和onclose，超时（如 3s）未触发onopen即判定不可用 - 对 iOS Safari 9–10、旧版 Android WebView，即使检测通过，首次连接也建议加兜底逻辑——收到空响应或
HTTP 503/400时主动切轮询 - 避免在页面初始化阶段就发起 WebSocket 连接；等 DOM 就绪、用户有交互意图（如进入聊天页）再触发检测与连接
轮询策略要分短轮询和长轮询，按场景选型
轮询不是“每隔几秒发个请求”这么简单，需匹配业务实时性要求与服务端能力：
- 短轮询：适合低频通知（如系统公告、离线消息提醒），间隔设为 3–5 秒；失败后启用指数退避（3s → 6s → 12s），并限制最大重试次数（如 5 次），防雪崩
- 长轮询：更适合类聊天场景，前端发请求后挂起等待，服务端有数据才响应；必须设服务端超时（推荐 25–30 秒），前端收到响应后立即发下一次请求；需处理重复消息（服务端加消息 ID 去重，前端缓存最近 10 条 ID）
- 所有轮询请求必须带
AbortSignal.timeout(8000)，防止网络卡顿导致请求长期 pending
统一接口，隐藏底层差异
业务代码不该关心当前走的是 WebSocket 还是轮询。对外暴露一致的通信契约：
立即学习“前端免费学习笔记（深入）”；
-
connect()：内部自动选择通道，成功后触发on('open', ...) -
send(data)：WebSocket 模式直发；轮询模式下将数据暂存队列，下次轮询请求携带（或另走 POST /api/send 接口） -
on('message', cb)：统一解析响应体，确保数据格式与 WebSocket 的event.data一致（如都为 JSON 字符串） -
close()：清除定时器、abort 所有 pending 请求、释放事件监听
注意运行时细节，避免内存和体验陷阱
降级不是一劳永逸，必须持续管理状态与资源：
- 监听
document.visibilityState，页面隐藏时暂停轮询（clearInterval或 abort controller），显示时恢复；减少后台电量与流量消耗 - 页面卸载前（
beforeunload）必须调用close()，否则轮询定时器可能泄漏，尤其在单页应用中易引发重复请求 - WebSocket 断连后，不要立刻切轮询；可先尝试重连 2 次（间隔 1s），失败后再降级；轮询稳定运行 30 秒且无错误后，可尝试反向切回 WebSocket（需服务端配合心跳探测）
