WebSocket应用层防丢消息需四步：唯一ID（客户端生成）、服务端收即落库、客户端即时ACK、重连后拉取未确认消息。
WebSocket 基于 TCP，本身不丢包，但网络抖动时应用层消息仍会“丢失”——不是传输丢了，而是连接未断、ACK 滞后或处理中断，导致消息没被业务逻辑真正接收或确认。解决的关键是绕过 TCP 的“假可靠”，在应用层补上四件事：唯一标识、服务端前置落库、客户端解耦 ACK、断连后上下文续传。
给每条消息加唯一 ID 并由客户端生成
不能依赖服务端发号，因为客户端可能已发送但服务端还没收到就断连。推荐组合方式：
- 用
crypto.randomUUID()（现代浏览器）或Date.now() + Math.random()生成高概率唯一 ID - 避免纯时间戳（存在回拨、并发重复风险）
- ID 随消息体一起发出，如：
{ id: "abc123", type: "chat", text: "hi" }
服务端收到即落库存储，再响应 ACK
不能“先广播再存库”，否则进程 panic 或 OOM 会导致消息蒸发。标准流程是：
- 解析消息 → 提取
id→ 插入数据库（status = 'received'） - 成功后立即向客户端返回
{ type: "ack", id: "abc123" } - 只有 ACK 发出后，才开始后续业务处理（如推送给其他用户）
客户端收到消息后立刻发 ACK，不等渲染完成
常见错误是把 ACK 写在 UI 更新之后，一旦页面卡顿或切后台，ACK 就延迟甚至失败，服务端误判为丢失而重发。
立即学习“Java免费学习笔记（深入）”；
- 监听到消息第一时间提取
id，调用ws.send(JSON.stringify({ type: "ack", id })) - 再走 setState / DOM 更新等耗时操作
- 可加简单防抖：若 500ms 内收到同 ID 的重复消息，直接忽略并重发 ACK
连接恢复时主动拉取未确认消息
客户端重连成功后，不能只等新消息，要主动同步状态：
- 携带上次连接的 session ID（如 JWT 中的
sid）发起重连 - 服务端查该 sid 下所有 status = 'received' 但无对应 ACK 记录的消息
- 批量推送这些消息，并重置它们的超时计时器（避免刚重连就触发重发）
