websocket移动端需以心跳探测为主实现可靠重连：连接后每20–30秒发ping，超时未收pong则主动close；配合指数退避重连、资源清理、上下文恢复及离线暂停机制。
WebSocket在移动端遇到Wi-Fi切4G、锁屏、弱网抖动等场景时，极易出现“假连”或无声断开——连接状态仍是OPEN，但发不出消息，onclose也不触发。真正可靠的重连，不能靠监听网络事件就贸然重连，而要以心跳探测为主、原生事件为辅、退避策略控频，再配合资源清理和上下文恢复。
用心跳主动探测，别等浏览器通知
移动端静默断连很常见（比如Nginx超时、运营商NAT掐断），onclose往往不执行。必须自己发业务层心跳：
- 连接打开后（
onopen），启动定时器，每20–30秒发送{type: "ping"}消息 - 收到服务端
{type: "pong"}立即重置心跳计时器 - 若连续2次未收到
pong（比如超时10秒），主动ws.close()并标记“连接失效” - 避免依赖
ws.ping()：JS WebSocket API不暴露该方法，必须走业务消息
重连逻辑要防抖+退避，不盲目轮询
一断就重连会压垮服务器、耗电、丢消息。正确做法是：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 统一由一个重连控制器管理，每次重连前清除旧定时器、监听器、
ws实例 - 采用指数退避：首次延迟1秒，失败后2秒、4秒、8秒……上限建议30–60秒
- 记录失败次数，达到阈值（如5次）暂停自动重连，等用户点击“重试”或
online事件触发 - 页面进入后台（
document.hidden === true）时暂缓重连，避免无效尝试
结合navigator.onLine做辅助，但不依赖它
navigator.onLine只是粗略信号，Chrome断电后也可能返回true，但它仍有价值：
- 监听
window.addEventListener("online", ...)，在网络恢复时触发一次重连检查 - 监听
"offline"时暂停心跳和重连，节省资源 - 绝不单独用它判断是否重连——比如Wi-Fi未断但心跳已超时，
onLine还是true
重连成功后要同步状态，不是简单重建
新连接建立后，光new WebSocket()不够，还要让服务端知道这是重连：
- 发送带标识的消息，如
{type: "reconnect", sessionId: "xxx"} - 服务端据此恢复未读消息、房间成员、订阅关系等上下文
-
前端缓存断线期间的
send()消息，重连成功后补发（需去重与幂等） - 确保全局只有一个
WebSocket实例，避免多连接冲突
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
