websocket本身不支持离线缓存，需应用层实现：客户端拦截发送动作，将待发操作序列化存入indexeddb等持久化存储，结合网络与连接状态监听，恢复后按序重放并保障幂等。
WebSocket 本身不支持离线缓存，断网时连接会关闭，消息无法发送。要在离线应用中实现“断网期间的操作队列缓存”，核心思路是：**主动接管发送逻辑，将待发操作暂存本地（如 IndexedDB 或 localStorage），网络恢复后自动重放**。这不是 WebSocket 自带能力，而是上层应用的设计模式。
1. 拦截发送动作，统一走缓存队列
不要直接调用 ws.send()，而是封装一个发送函数，所有业务操作都调用它：
- 在线时：直接通过 WebSocket 发送，并标记该操作已提交
- 离线时：序列化操作数据（如 {type: 'update', id: 123, data: {...}}），存入持久化存储（推荐 IndexedDB，支持结构化数据和事务）
- 为每条记录添加时间戳、唯一 ID、重试次数等元信息，便于去重和限重试
2. 监听网络状态 + WebSocket 连接生命周期
仅靠 navigator.onLine 不可靠（它只反映浏览器是否认为联网，不保证 WebSocket 可连）。应结合：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
window.addEventListener('online')和'offline'做粗粒度判断 -
ws.onclose/ws.onerror触发时，视为连接异常，启动离线缓存模式 -
ws.onopen触发后，立即启动队列重放（注意防重复重放） - 建议加定时心跳或尝试重建连接的逻辑，避免长期假连
3. 离线队列重放策略（关键细节）
重放不是简单 for 循环发一遍，需考虑实际业务约束：
- 顺序性：按入队时间顺序重放（尤其涉及增删改依赖的操作）
- 幂等性：服务端必须支持幂等（如带 client_id + seq_no），避免重复提交导致脏数据
- 冲突处理：若重放时服务端返回 409（冲突）或业务校验失败，需有降级策略（如丢弃、告用户、转为本地合并）
- 失败回退：单条重放失败，记录 error 并暂停队列，避免阻塞后续；提供手动重试接口
4. 存储选型与清理机制
缓存不是无限制堆积，需合理管理生命周期：
- 优先用 IndexedDB：可存对象、支持索引、容量大（通常 ≥ 50MB），适合操作队列
- 避免仅用
localStorage：只能存字符串、无事务、容量小（~5–10MB）、同步阻塞 UI - 设置过期策略：如只保留最近 24 小时或最多 100 条未确认操作
- 成功重放且服务端确认后，从队列中安全删除对应记录（使用 ID 删除，非清空）
本质上，这是在 WebSocket 之上构建一层具备离线能力的“可靠消息通道”。WebSocket 负责实时通信，而队列缓存、重试、状态同步由应用自己兜底。只要服务端配合幂等与状态反馈，这套方案就能支撑高质量的离线交互体验。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
