websocket原生不保证消息100%到达，writemessage()返回nil仅表示数据写入内核缓冲区；可靠送达需应用层实现id+ack+超时重发闭环，并在连接断开时通过会话id主动补发未确认消息。
WebSocket 原生不保证消息 100% 到达，WriteMessage() 返回 nil 只代表数据进了内核缓冲区，不代表客户端收到、解码成功、业务处理完成。所谓“100% 不丢失”，本质是应用层兜底的结果，不是协议能给的承诺。
为什么 conn.WriteMessage() 成功 ≠ 消息送达
常见错误现象：conn.WriteMessage() 返回无错，但前端永远没渲染；服务端日志显示“已发送”，用户投诉订单状态没同步。
- TCP 层只管字节流可靠传输，不关心上层是否调用
JSON.Unmarshal()、是否更新了 DOM、是否写入数据库 - 中间代理（如 Nginx）可能静默关闭空闲连接，此时
WriteMessage()仍可能成功返回（因写入的是未被探测到断开的 socket 缓冲区） - 客户端闪退、标签页关闭、App 切后台时，ACK 回执根本发不出来
- 服务端在广播前崩溃，消息只存在内存里，未持久化
必须实现 ID + ACK + 超时重发闭环
这不是加个回调就能解决的逻辑，关键在状态生命周期与失败归因。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 每条业务消息结构必须含可序列化
ID：建议用uuid.NewString()，避免时间戳+计数器在多实例下冲突 - 服务端发送后立即启动
time.AfterFunc(timeout, func())，用sync/atomic.Bool标记是否收到ack:{id} - 客户端收到消息后，必须「先发 ACK、再执行业务逻辑」；顺序反了会导致重复处理（比如订单重复扣款）
- 超时未 ACK 的消息不能直接丢弃：要记录日志 + 触发告警，3 次重试失败应进死信队列，而非静默吞掉
连接断开时，未确认消息怎么兜住
断连瞬间，所有未 ACK 消息失效。靠“重连后拉全量”是懒办法，会放大延迟和压力。
- 服务端需为每个会话维护一个带 TTL 的待重发缓存（如
map[string][]*Msg），键为用户sid - 新连接携带相同
sid上线后，服务端主动扫描该sid对应缓存，逐条补发未确认消息 - 缓存本身要配定期清理 goroutine，防止内存泄漏；TTL 建议设为 5–10 分钟，比单次超时长但不过度堆积
- 客户端重连后，需同步本地
pendingMessagesMap 中未 ACK 的 ID 列表，和服务端比对，避免补发已处理消息
为什么别用 RabbitMQ / Redis 中转来“增强可靠性”
这不是增强，是错配——它把端到端问题拆成两段不可控链路。
- RabbitMQ 保证的是 A→B（服务间）投递，不保证 B→终端（WebSocket 连接）送达；多一跳反而引入新故障点（MQ 宕机、消费者 crash、序列化失败）
- 延迟增加：消息从 MQ 出队 → WebSocket 广播 → 客户端接收 → ACK 返回 → MQ 确认，整个链路变长且不可测
- ACK 无法跨层穿透：MQ 的
ack和 WebSocket 的ack是两套语义，混用会导致状态混乱（比如 MQ 认为成功，但 WebSocket 已断连） - 真正该持久化的，是服务端内存中那条“已发未确认”的消息元数据，不是原始消息体本身；用 Redis 存
map[sid]map[id]msgMeta就够用
最易被忽略的点：消息去重必须由接收方完成，且去重逻辑不能依赖服务端时间或序号——因为重发可能乱序到达，唯一可靠的锚点只有客户端生成的 ID。只要这个 ID 在接收方本地有记录，不管来几次都只处理一次，但每次都要回 ACK。
