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