WebSocket原生不保证消息送达，conn.WriteMessage()成功仅表示数据进入内核缓冲区；“百分百送达”需应用层实现ID+ACK机制，含唯一消息ID、服务端超时重发、客户端幂等处理及断连后会话级消息兜底。
WebSocket 本身不提供消息送达保证，conn.WriteMessage() 返回 nil 只代表数据进了内核缓冲区，不代表对方收到、解码成功或业务处理完成。所谓“百分百送达”，必须靠应用层补全 ACK 协议，不是加个回调就能解决的事。
为什么 conn.WriteMessage() 成功了，前端却没显示消息
这是最典型的误判场景：服务端日志写着“send ok”，但用户根本没看到。原因包括：
- 客户端网络闪断，消息卡在中间代理（如 Nginx）或 TCP 连接半关闭状态，未被上层应用读取
- 前端 WebSocket
onmessage回调执行前页面已刷新/崩溃 - 消息到达后，前端解析失败（比如 JSON 字段缺失导致
JSON.parse()报错，后续逻辑中断） - 服务端发完就丢，没维护任何状态，断连后无从追溯哪些消息丢了
如何设计带 ID 的消息 + ACK 回执结构
核心是让每条业务消息可追踪、可验证、可重放。关键不在“发”，而在“谁发的、发给谁、有没有被认领”。
- 消息体必须含
ID字段，建议用uuid.NewString()或time.Now().UnixNano()拼接会话标识，避免跨连接冲突 - 服务端发送后，立即将
ID → {msg, timestamp, retryCount}存入内存 map 或 Redis（集群必备），并启动time.AfterFunc(timeout, ...)定时器 - 客户端收到后，**必须先提取
ID，立即发{"type":"ack","id":"xxx"}，再执行 UI 更新或业务逻辑**；顺序颠倒会导致 ACK 延迟甚至丢失 - 服务端收到
ack后，从待确认队列中移除对应ID；超时未收则按策略重发（最多 2–3 次），超过阈值记日志并告警，不静默丢弃
连接断开时未确认消息怎么兜住不丢
单纯重连后“拉最新 20 条”不能解决回执问题——那 20 条里可能包含已被读过但未 ACK 的消息，造成重复或状态错乱。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 每个 WebSocket 连接需绑定唯一会话 ID（例如从 JWT 中解析出
sid），服务端用map[string]*ConnState管理，其中ConnState包含未 ACK 消息列表和最后心跳时间 - 连接断开（
conn.ReadMessage()返回*websocket.CloseError或io.EOF）时，仅标记该sid为 offline，不清空未确认队列 - 新连接携带相同
sid上线后，服务端检查其待重发队列，逐条调用conn.WriteMessage()补发，并为每条重置超时计时器 - 客户端需支持幂等处理：收到重复
ID的消息时，若本地已存对应记录，跳过 UI 渲染但仍回复ack
STOMP 场景下 ACK 怎么适配
用 Spring Boot + STOMP 时，WebSocketSession 生命周期与原生连接不同，ACK 不能只依赖底层连接状态。
- 不要把 ACK 绑定到
WebSocketSession的close事件——它可能晚于实际断连，且无法区分“主动关闭”和“网络异常” - 改用
@MessageMapping处理ack消息，服务端收到后通过SimpMessagingTemplate查找对应sessionId的待确认项 - STOMP 订阅路径（如
/user/queue/notifications）天然支持用户粒度，ACK 消息应走/app/ack这类自定义路径，避免和广播消息混在一起 - 集群部署时，未确认消息必须落 Redis，否则新节点无法感知老节点上的 pending 队列
真正难的不是发 ACK，而是让 ACK 在各种异常路径下都保持语义一致：断连重连、多端登录、页面刷新、消息乱序到达……这些边界情况一旦漏掉一个，就可能出现“已读未回执”或“重复回执”。别把 ACK 当成锦上添花的功能，它是整个实时链路的状态锚点。
