onclose回调中拿不到关闭原因，是因为网络中断、标签页关闭等异常场景下服务端未发送规范close frame，此时event.code恒为1006且reason为空；应优先依据code判断而非reason字符串匹配。
onclose 回调里为什么拿不到关闭原因？
WebSocket 的 onclose 回调接收一个 CloseEvent 对象，但它的 code 和 reason 字段在某些场景下是空的——比如网络突然中断、浏览器标签页被关闭、代理主动断开，或者服务端未按规范发送 close frame。此时 event.code === 1006（abnormal closure）是唯一可靠信号，不能依赖 reason 做业务判断。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先检查
event.code：1000 表示正常关闭；1001（going away）、1005（no status）、1006（abnormal）都应视为需重连 - 避免用
event.reason === "network error"这类字符串匹配，浏览器不会填充该字段 - 在
onclose中立即记录时间戳，用于后续判断是否属于“频繁断连”
自动重连该不该在 onclose 里直接 new WebSocket？
不能直接在 onclose 回调里执行 new WebSocket(url)。因为 onclose 可能被多次触发（例如服务端反复断连又重发 close），且此时旧实例尚未完全释放，直接新建会引发连接竞争、内存泄漏或 INVALID_STATE_ERR 错误。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用一个布尔标志位（如
isReconnecting）控制重连入口，确保同一时间只有一条重连路径在跑 - 使用
setTimeout延迟发起新连接，哪怕仅delay = 0，也能把任务推入宏任务队列，避开同步冲突 - 每次重连前先清理上一次的定时器和监听器，防止重复绑定
onopen/onmessage
如何设计带退避策略的重连逻辑？
无限制重试会压垮客户端和服务端。合理做法是指数退避（exponential backoff），从 1s 开始，每次失败翻倍，上限设为 30s 左右，并加入随机抖动防雪崩。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 维护一个重试计数器
retryCount，每次重连失败后递增；成功后重置为 0 - 计算延迟：
Math.min(30000, Math.pow(2, retryCount) * 1000 + Math.random() * 500) - 超过最大重试次数（如 10 次）后暂停自动重连，改由用户手动触发或弹出提示
- 注意：不要把退避逻辑写死在
onclose内，应封装成独立函数，便于测试和复用
重连时怎么避免消息丢失和状态错乱？
WebSocket 断开期间产生的消息如果只是简单丢弃，会导致 UI 状态滞后；而盲目缓存所有消息又可能撑爆内存。关键是要区分「可重发」和「不可重发」操作。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对服务端有幂等保障的请求（如
GET /status），可在重连成功后主动拉取最新状态 - 对带副作用的操作（如
send({type: "submit_order"})），应在发送前存入队列，并在onopen后逐条重发，配合服务端去重 ID - UI 层需监听连接状态变化，禁用提交按钮、显示「重连中…」，避免用户重复点击造成重复提交
- 不要在
onclose中清空本地缓存数据——除非明确知道服务端已失效，否则应保留最后有效快照
重连不是“断了就建”，而是要结合连接生命周期、网络可观测性、业务语义做协同判断。最容易被忽略的是：没区分 1006 和 1001 的处理路径，以及在 onclose 里直接 new WebSocket 导致的竞态问题。
