HTML5中WebSocket处理服务器维护期间的优雅断连逻辑

WebSocket断连时关键在于客户端感知、归因与平滑恢复：通过close事件+自定义状态码（如4001）区分维护与故障，结合HTTP健康接口轮询、指数退避重连、本地消息缓存及用户提示降级，实现优雅体验。

WebSocket 在服务器维护期间断连时，关键不是“避免断开”，而是让客户端感知断连、区分原因、合理重连，并在恢复后平滑续传。核心在于结合 close 事件、自定义状态码、心跳机制与退避重连策略。

监听 close 事件并识别维护信号

服务器主动关闭连接时，应使用 WebSocket 规范中保留的、服务端可自定义的状态码（如 4000–4999）传递语义信息。例如，维护中发送 close(4001, "maintenance")。

客户端需在 onclose 中检查 event.code 和 event.reason：

• 若 code === 4001 或 reason.includes("maintenance")，标记为“计划性维护”，暂停自动重连或延长重试间隔
• 若 code === 1006（异常关闭）或超时无响应，则按网络故障处理，启用快速重试
• 避免仅依赖 event.wasClean === false 判断——它无法区分宕机和主动维护

配合心跳与服务器健康探针

单纯靠 WebSocket 连接状态不足以判断服务是否就绪。应在维护前/中提供轻量 HTTP 接口（如 /api/v1/status），返回 JSON：

立即学习“前端免费学习笔记（深入）”；

{ "status": "maintenance", "until": "2025-04-12T14:30:00Z", "message": "系统升级中" }

客户端可在检测到断连后，立即轮询该接口：

• 返回 status: "ok" → 尝试重建 WebSocket
• 返回 status: "maintenance" → 显示提示、禁用交互、定时轮询（如每 30 秒一次）
• HTTP 请求失败或超时 → 回退为网络异常逻辑

实现带退避与上下文保持的重连

维护期间不盲目重连，但需在恢复后快速重建并续传未确认消息：

• 使用指数退避（如 1s → 2s → 4s → 8s），上限设为 30 秒；对维护码（如 4001）初始延迟可设为 15 秒起
• 维护期间暂停发送新业务消息，但缓存本地待发队列（如聊天输入、表单提交），设置 TTL 防止堆积
• 重连成功后，先发送握手帧（如 {"type":"resync","seq":123}），服务端据此补推丢失事件或确认已收消息

用户提示与界面降级体验

优雅不只体现在代码逻辑，更体现在用户感知：

• 断连时若判定为维护，显示非侵入式 toast：“系统正在升级，功能将暂时不可用，预计 14:30 恢复”
• 禁用依赖实时通信的按钮（如“发送消息”），但保留离线可操作项（如编辑草稿、查看本地历史）
• 恢复连接后自动刷新关键状态（如订单状态、通知红点），而非静默重连