websocket本身不提供离线缓存能力，需自行构建消息队列、重连机制与本地持久化策略：发送前入队并持久化，断连时指数退避重连并重发未确认消息，接收端依赖服务端消息回溯与本地缓存协同，辅以队列限长、敏感操作拦截及状态提示。
WebSocket 本身不提供离线缓存能力，因为它依赖于持续的、双向的实时连接。当网络中断时，连接会断开，消息无法收发，也不会自动暂存。要实现“网络不佳时的离线缓存”，必须在 WebSocket 协议之上**自行设计消息队列 + 重连机制 + 本地持久化策略**。
1. 消息发送前先入本地队列
所有需要发出的消息，不要直接调用 ws.send()，而是先存入一个内存或持久化队列中：
- 使用
localStorage或IndexedDB存储待发消息（推荐 IndexedDB，支持结构化数据和较大容量） - 每条消息建议带唯一 ID、时间戳、类型、重试次数、过期时间等元信息
- 发送成功后，从队列中移除对应消息（需服务端确认或客户端 ACK 机制）
2. 监听连接状态并智能重连
仅靠 onclose 不够，需结合网络状态与连接心跳判断是否真离线：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 监听
window.navigator.onLine变化，但注意它只反映浏览器层面联网状态，不能替代真实连接检测 - 建立应用层心跳（如每 15s 发送 ping，超时未收到 pong 则标记为“疑似断连”）
- 断连后暂停新消息发送，启动指数退避重连（如 1s → 2s → 4s → 最大 30s）
- 重连成功后，按顺序重发队列中未确认的消息（可加去重逻辑，避免重复提交）
3. 接收消息的离线兼容处理
WebSocket 断开期间，服务端推送的消息客户端无法接收——这部分无法由客户端单方面补全，需服务端配合：
- 服务端保留用户最近 N 条消息（如 5 分钟内未读消息），客户端重连后主动拉取（例如发送
{"type":"sync_history","since":171xxxxx}） - 客户端可将关键业务消息（如订单状态变更）同时写入 IndexedDB，并在页面加载时优先展示本地缓存状态
- 对非实时性要求高的消息（如通知、日志），允许“离线可见、上线同步”模式：先渲染本地缓存内容，再与服务端对账修正
4. 用户体验与边界控制
缓存不是万能的，需明确限制和降级策略：
- 设置队列最大长度（如 100 条）和单条消息最大存活时间（如 24 小时），避免无限堆积
- 敏感操作（如支付、密码修改）禁用离线发送，强制联网执行
- 界面上清晰反馈当前状态：“正在离线缓存…”、“已同步 X 条消息”、“部分消息可能丢失，请刷新重试”
- 避免在离线状态下触发强依赖 WebSocket 的逻辑（如实时协作光标、音视频信令）
本质上，这不是 WebSocket 的功能扩展，而是围绕它构建的一套具备容错能力的通信层。核心思路是：发送可暂存、连接可恢复、接收可补漏、体验有兜底。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
