conn.WriteMessage()返回nil仅表示数据写入内核缓冲区，不保证客户端接收或处理成功；真正可靠送达需应用层实现ID+ACK机制，配合超时重试、持久化与去重策略。
conn.WriteMessage()返回nil ≠ 消息已送达
这是最常被误判的点。Go 的 websocket.Conn.WriteMessage() 成功返回，只代表数据写入了内核 socket 缓冲区，不表示客户端收到、解码成功，更不防代理（如 Nginx）静默断连或浏览器进程崩溃。弱网下尤其明显：前端调用 send() 返回 true，但服务端日志里压根没这条消息。
关键判断依据是：conn.WriteMessage() 后立即检查 conn.WriteBufferPool 或 conn.SetWriteDeadline() 配合超时，但这仍不能替代应用层确认。真正可靠的信号，是客户端主动回的 ACK 帧。
- 不要依赖
err == nil就认为发送成功；它只是“没在写入阶段出错” - 若需强保障，必须在业务逻辑外包裹一层 ID + ACK 流程，而不是改写
WriteMessage调用方式 - Nginx 默认 60s 关闭空闲连接，且不会转发未完成的帧——这意味着你得在服务端主动 ping/pong，并在断连前清理未 ACK 消息
如何设计可落地的 ACK 消息结构与生命周期
不是所有消息都值得加 ACK，但订单变更、支付结果、协同编辑指令这类必须“发即达”的场景，必须定义清晰的协议边界。核心是让每条消息可追溯、可重试、可去重。
推荐结构（JSON）：
{ "id": "msg_9f3a2b1e", "type": "order_update", "data": { "order_id": "ORD-7890", "status": "paid" }, "ts": 1748294301 }
-
id必须全局唯一，建议用uuid.NewString()（Go）或crypto.randomUUID()（JS），避免时间戳+随机数拼接带来的碰撞风险 -
type字段用于服务端路由和幂等处理，不要只靠id做判断 - 服务端收到后，先持久化到 DB/Redis（状态为
received），再发 ACK；否则服务器宕机，消息就真丢了 - 客户端收到消息后，必须「解析 id → 立即发 ACK → 再执行 UI 更新」，顺序错乱会导致重复提交或状态不一致
高并发下未 ACK 消息怎么兜住不爆炸
单机万级连接时，每个连接维护一个 map 存 pending 消息，内存会撑爆；全量存 Redis 又引入延迟和一致性问题。得做分层缓冲。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
推荐三级队列策略：
- 内存层（
sync.Map）：存最近 30 秒、最多 100 条未 ACK 消息，key 是connID + messageID，value 含原始 payload 和重试次数 - 本地存储层（SQLite / Badger）：连接断开时，把内存中未 ACK 消息刷入本地磁盘，重启后加载；适合 PWA 或桌面客户端
- 服务端中心层（Redis Sorted Set）：以
messageID为 member，score 为过期时间戳，用ZRANGEBYSCORE扫描超时项触发告警或补偿；避免用 Hash 存，不然没法按时间批量清理
注意：Redis 不是万能兜底。如果服务端在写入 Redis 前崩溃，而消息又没落库，照样丢失。所以「先 DB 持久，再发 ACK，最后异步推 Redis」才是安全顺序。
重试 + 去重的临界点在哪
重试不是越多越好。3 次重试 + 5s 初始间隔（指数退避）是多数场景的合理起点。超过这个阈值还没 ACK，大概率是客户端已离线或网络彻底中断，继续重发只会加重服务端负担。
- 客户端重试时，必须检查当前连接状态：
ws.readyState === WebSocket.OPEN，否则直接丢弃或进离线队列 - 服务端去重不能只看
messageID是否存在，还要结合senderID + timestamp ± 30s判断是否为同一操作的重复提交 - ACK 帧本身也要带
id（比如{"type":"ack","for_id":"msg_9f3a2b1e"}），防止 ACK 丢失导致无限重发 - 别忽略心跳包干扰：ping/pong 帧不该计入消息 ID 体系，也不该触发 ACK，否则会污染待确认队列
最易被忽略的是 ACK 的语义：它代表“消息已成功处理并落库”，不是“我收到了字节流”。这个边界一旦模糊，整个可靠性链条就断了。
