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 恢复”
- 禁用依赖实时通信的按钮（如“发送消息”），但保留离线可操作项（如编辑草稿、查看本地历史）
- 恢复连接后自动刷新关键状态（如订单状态、通知红点），而非静默重连
