当浏览器不支持 websocket 时，应通过合理设计的轮询策略（短/长轮询）、统一接口封装、自动切换逻辑及资源管理来实现平滑降级。需检测 websocket 可用性、设置超时与退避机制、同步连接状态，并在页面隐藏时暂停轮询以优化性能。
当浏览器不支持 WebSocket 时，可通过轮询（Polling）作为降级方案维持实时通信能力。关键不是简单“有轮询就行”，而是要合理设计轮询策略、状态管理与自动切换逻辑，避免资源浪费或体验断层。
检测 WebSocket 支持并准备降级入口
在建立连接前，先判断 window.WebSocket 是否存在且可用：
- 仅检查构造函数存在还不够，需结合
typeof WebSocket === 'function'和!window.MSStream（排除旧版 IE 的伪支持） - 建议封装一个
canUseWebSocket()工具函数，返回布尔值，并在初始化时调用 - 若不支持，立即启用轮询模块（如基于
fetch或XMLHttpRequest的长轮询/短轮询），但暂不发起请求，留待连接状态触发
轮询策略要区分场景：短轮询 vs 长轮询
短轮询（固定间隔发请求）适合低频、容忍延迟的场景；长轮询（服务端挂起响应直到有数据）更接近 WebSocket 体验：
- 短轮询：间隔建议 2–5 秒，配合指数退避（如失败后延至 4s → 8s → 16s），防止雪崩请求
- 长轮询：后端需支持超时控制（如 30s），前端收到响应后立即发起下一次请求；需处理网络中断、空响应、重复消息等问题
- 无论哪种，都要设置请求超时（如
AbortSignal.timeout(8000)），避免请求长期挂起
统一连接状态与消息通道接口
WebSocket 和轮询应对外暴露一致的 API，降低业务层适配成本：
- 定义统一的
connect()、send(data)、on('message', cb)、close() -
send()在轮询模式下可转为“发送到队列+下次轮询携带”，或直接走独立 HTTP 接口（如 POST /api/msg） - 使用事件总线或 Promise 链管理重连逻辑，例如：WebSocket 断开后尝试重连 3 次失败，则自动切换至轮询；轮询恢复后也可反向切回 WebSocket（需服务端配合）
注意兼容性细节与资源释放
降级不是一劳永逸，需兼顾内存、网络与用户体验：
- 轮询定时器必须在
close()或页面卸载时清除（clearInterval/abortController.abort()），防止内存泄漏 - 监听
visibilitychange事件：页面隐藏时暂停轮询，显示时恢复，节省电量和带宽 - 对低版本 Android WebView 或 iOS Safari 9-10，即使声明支持 WebSocket，也可能存在握手失败问题，建议结合实际连接结果二次判断，再决定是否降级
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
