一、接收方离线问题接收方未建立连接用户压根就没有建立 WebSocket 连接APP 没打开、页面没打开服务端无处推送消息丢失。方案消息持久化 上线补推。客户端重连后拉取未读消息。二、发送缓冲区满TCP 内核层面问题服务端往 socket 写消息操作系统内核的 TCP 发送缓冲区塞满了缓冲区溢出后消息被丢弃或连接被断开。方案增大发送缓冲区写入失败时落库异步重试背压机制检测到慢消费者时主动降速或断开三、网络闪断 / 连接中途断开问题TCP 有半开连接问题服务端不知道客户端已掉线继续往死连接写消息。方案心跳检测Ping/Pong超时判定断连消息序列号sequence重连之后按序列号补中间断掉这段时间的消息四、服务端重启 / 崩溃问题内存中的连接和消息全部丢失。方案消息写 DB 后再推送先落库后投递重启后扫描未送达记录主动补推集群部署时用 Redis/MQ 做消息中转避免单点故障五、集群多节点部署问题用户连在节点 A发送方连在节点 BB 找不到用户连接消息推不过去。方案引入 Redis Pub/Sub 或消息队列RabbitMQ/Kafka做跨节点广播消息发给全部节点每个节点判断用户是不是在自己本机是就推送。简单但是消息量大的时候很耗性能。维护全局的用户-节点映射表精准路由查表只把消息转发给用户所在的那一台节点减少无效消息六客户端处理不过来问题客户端收到消息但处理不及时造成浏览器 / App 崩溃页面关闭后消息在客户端丢失。方案应用层 ACK客户端处理完回复确认服务端未收到 ACK 则重发客户端本地存储IndexedDB/SQLite断线恢复后两边对账补WebSocket 底层是 TCP。 只要数据包成功传到客户端电脑 / 手机的操作系统操作系统就会给服务端回 TCP ACK这个 ACK 只能证明消息已经到达客户端机器不代表页面 / App 业务逻辑处理完消息了应用层 ACK 是我们自己在业务代码里新增的确认代表【客户端业务代码已经成功处理完这条消息】​ 在 WebSocket 的消息协议里我们自己约定服务端推消息的时候每条消息带上唯一msgId客户端等业务逻辑完全处理完毕比如存入本地 IndexedDB、页面渲染完成再主动发一条特殊消息给服务端ACK msgId服务端收到这个应用层 ACK才认为这条消息投递成功如果超时没收到这个 ACK就判定客户端处理失败重新推送这条消息****