WebSocket断线重连怎么写 JavaScript实现WebSocket自动重连逻辑【代码】-js教程-PHP中文网

websocket断线后onclose不触发重连，主因是实例未真正连接即关闭或事件绑定过晚；应立即绑定onopen/onerror/onclose，用readystate判断重连条件，安全发送需封装检查并缓存消息，心跳保活优先依赖服务端ping/pong。

websocket断线重连怎么写 javascript实现websocket自动重连逻辑【代码】

WebSocket断线后 `onclose` 不触发重连？检查连接状态和事件绑定时机

很多同学发现 onclose 没执行，或者执行了但重连没起来——根本原因是 WebSocket 实例还没真正建立连接，就因网络抖动或服务未就绪提前关闭，此时 onclose 会触发，但 readyState 可能还是 0（CONNECTING），甚至直接跳过 1（OPEN）。更关键的是，如果在 new WebSocket(...) 后立刻绑定 onclose，但实例在绑定前已失败（比如 DNS 解析失败、跨域拒绝），事件根本不会派发。

实操建议：

使用HTML,CSS,JavaScript开发Android应用程序英文文字pdf版附源文件

如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更

下载

始终在 new WebSocket(...) 之后**立即**绑定 onopen、onerror、onclose，不要延迟或条件绑定
在 onclose 和 onerror 中都触发重连逻辑，因为某些底层错误（如 TLS 握手失败）只走 onerror
用 ws.readyState === WebSocket.CONNECTING || ws.readyState === WebSocket.OPEN 判断是否值得重连，避免对已销毁实例重复操作

重连时不断创建新 WebSocket 实例，导致内存泄漏和连接风暴

常见错误是每次重连都 new WebSocket(url)，却不清理旧实例。即使旧实例已关闭，若还持有 onmessage 回调里的闭包引用（比如绑定了 this 或外部变量），它就不会被 GC；同时大量未关闭的 socket 还可能触发浏览器并发限制（Chrome 默认 6 个同源 WebSocket）。

实操建议：

每次新建实例前，先调用 ws.close()（如果 ws 存在且 readyState 是 1 或 0）
把 WebSocket 实例赋值给一个可覆盖的变量（如 let ws = null），重连前先清空引用
加一个简单防抖：两次重连间隔不低于 1s，避免网络完全不可用时疯狂重试（可用 setTimeout + 递增退避，比如 1s → 2s → 4s → 最大 30s）

如何安全地发送消息？避免 `ws.send() failed: InvalidStateError`

这个错误几乎都发生在 ws.readyState !== WebSocket.OPEN 时调用了 send()。自动重连期间，应用层代码可能不知道连接已断，还在往旧实例发消息；或者重连刚发起，ws 已是新实例但还没 open，就急着发数据。

实操建议：

封装一个 safeSend(data) 函数，内部检查 ws?.readyState === WebSocket.OPEN，否则缓存到队列（pendingQueue.push(data)）
在 onopen 回调里批量发送缓存消息（注意控制速率，避免拥塞）
不要在 onclose 后立刻尝试发消息，等下次 onopen 确认连接稳定后再恢复业务逻辑

要不要用 `setInterval` 心跳保活？多数场景其实不需要

WebSocket 协议本身不强制心跳，浏览器和大多数代理（Nginx、CDN）默认会在 60–300 秒无数据时断开空闲连接。但如果你的业务消息本身就足够频繁（比如每 10 秒有业务帧），再加心跳纯属冗余；反之，如果长周期无交互（如监控后台），又没服务端支持 ping/pong，那客户端单方面发心跳也没用——服务端可能直接忽略。

实操建议：

优先确认服务端是否支持 ping/pong 帧（由服务端主动发 0x9 frame），这是最轻量的保活方式
若服务端不支持，再考虑客户端定时发业务无关的 JSON.stringify({ type: 'ping' })，并配对监听 pong 响应
心跳间隔设为比服务端超时时间小 10–20 秒（例如服务端超时 120s，客户端每 100s 发一次）

重连逻辑真正难的不是写几行 setTimeout，而是处理好状态跃迁边界：连接中、正在重连、重连失败、服务端拒绝、网络彻底离线……这些状态之间不能靠 readyState 单一字段判断，得结合时间戳、错误码（event.code）、重试次数共同决策。漏掉任意一种，都会让“自动重连”变成“自动失联”。