WebSocket原生不保证消息可靠投递，需应用层实现四层机制：唯一标识（message_id）、持久前置（发送前存缓存、服务端落库）、客户端ACK（解析后立即回传）、断连上下文保留（pendingQueue+重连重发）。
WebSocket 原生不保证消息可靠投递——send() 成功只代表数据进了浏览器 socket 缓冲区，不代表对方收到、解析、处理成功。要实现“发出去 = 对方已处理”，必须在应用层补足四层机制：唯一标识、持久前置、客户端 ACK、断连上下文保留。
加唯一 ID，让每条消息可追踪
所有业务消息需携带全局唯一 message_id（如 crypto.randomUUID() 或时间戳+随机数），服务端据此去重、客户端据此匹配 ACK。不能复用 ID，否则幂等失效；也不能仅靠时间戳，避免并发或时钟回拨冲突。
- 前端发送前生成 ID，并存入待确认缓存（Map 或 IndexedDB）
- 服务端收到后立即落库（status: 'received'），再执行业务逻辑
- 响应中必须回传该 ID，便于前端关联原始请求
强制客户端 ACK，不依赖“推送即完成”
服务端推送消息后，不认为送达；只有收到客户端带对应 message_id 的 ACK，才更新状态为“已送达”。ACK 必须第一时间发出——收到消息解析成功后立刻发，不要等 UI 渲染或业务处理完。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 前端 onmessage 中提取 message_id，立即 ws.send({ type: 'ack', id: 'xxx' })
- 服务端收到 ACK 后，从待确认队列移除并更新 DB 状态
- 若未收到 ACK，服务端按策略重发（如 3s 后、6s 后、12s 后）
连接未就绪时自动排队，不抛错也不丢弃
调用 send() 前检查 readyState !== 1 时，不强行发送，而是推入 pendingQueue；连接建立（onopen）后批量重放。重连场景下，队列不清空，避免重连窗口期消息丢失。
立即学习“Java免费学习笔记（深入）”；
- 封装 sendMessage(msg) 方法，内部判断状态：就绪则直发，否则入队
- 每次新建 WebSocket 实例时，绑定一次 onopen，清空并遍历队列发送
- 队列中消息保持原始类型（string / ArrayBuffer / Blob），不转换
结合序列号与幂等键，防乱序和重复
对强一致性操作（如转账、状态变更），光有 message_id 不够，还需 seq（单调递增）+ idempotency_key（业务唯一哈希）。服务端用 Redis 缓存 idempotency_key 5–10 分钟，重复即拒收；seq 用于检测缺失与排序。
- 客户端用 localStorage 持久化上一个 seq，每次发新请求前 +1 并保存
- idempotency_key 推荐用 sha256(JSON.stringify({type, payload})) 生成
- 服务端响应必须 echo seq 和 idempotency_key，前端据此校验和去重
