WebSocket本身不提供“已读”语义，必须由业务层主动上报、后端状态维护（如位图存储）、客户端联动（IntersectionObserver监听可视区域）共同闭环，避免误判与高并发瓶颈。
WebSocket 本身不提供“已读”语义，必须靠业务层主动上报 + 后端状态维护 + 客户端联动才能闭环。只靠 onMessage 接收到消息就标记“已读”，是常见误判。
客户端怎么触发“已读”通知才合理
不能一收到消息就发已读回执——用户可能根本没看到。真实场景下，“已读”应由前端在消息进入可视区域或用户点击展开时触发：
- 用
IntersectionObserver监听消息 DOM 元素是否出现在视口内，entry.isIntersecting === true且持续 >200ms 再发 - 群聊中需区分“单条消息已读”和“会话已读”：前者发
{ type: "READ", messageId: "123" }，后者发{ type: "READ_ALL", chatId: "g456" } - 避免重复发送：每个
messageId对应的已读通知只发一次，前端本地用new Set()缓存已触发 ID - 离线时不发：检查
navigator.onLine，断网期间暂存已读 ID 列表，重连后批量补发
后端怎么存已读状态才扛得住并发
直接对每条消息、每个用户写一行 read_status 表，在千人级群聊里就是万级写入，DB 很快被打爆。位图（bitmap）是更优解：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 一条消息最多支持 1024 个接收者 → 用 128 字节字符串（
CHAR(128)）存所有用户已读位，第 N 位为 1 表示 UID=N 的用户已读 - 内存中用
Swoole\Table或ConcurrentHashMap<string byte></string>管理脏位图，避免每次操作都查 DB - 更新位图用原子操作：
bits[n / 8] |= (1 ，查状态用 <code>(bits[n / 8] >> (n % 8)) & 1 - 批量落库：定时器每 3 秒扫描所有脏位图，拼成单条
INSERT ... ON DUPLICATE KEY UPDATE执行
WebSocket 怎么把已读变化实时推给发送方
已读回执不是单向写 DB，它要立刻让发送方感知到——这需要服务端维护“谁发了哪条消息”这个映射关系：
- 消息入库时记录
sender_id和msg_id，并缓存在ConcurrentMap<string string></string>中（msg_id → sender_id） - 当某用户 A 标记消息 M 已读，后端查出发送者 B，再通过
sessionMap.get(B)找到 B 的 WebSocketSession - 推送格式统一为
{ "type": "READ_ACK", "messageId": "m789", "readerId": "u123", "timestamp": 1716625680 }，避免前端再解析 - 如果发送方不在线，这条 ACK 不丢弃，而是进 Kafka Topic
topic_message_readStatus_writeBack，等其重连后从 Redis 未读队列里补推
为什么 MySQL 的 ENUM('SENT','DELIVERED','READ') 不适合高并发已读场景
这种字段设计在单聊或低频场景没问题，但一旦涉及群聊+多设备+快速滚动，就会暴露三个硬伤：
- 每条消息对每个用户都要 UPDATE 一次，1000 人读 = 1000 次行锁，极易引发死锁和慢查询
- 无法高效回答“这条消息有多少人已读”：得
COUNT(*) WHERE status = 'READ'，全表扫描不可接受 - 状态不可逆：用户撤回已读（比如误点）很难还原，位图却可直接清零对应 bit
- 扩展性差：加个“已转发”状态就得改 ENUM，而位图预留 8 位就能支持 8 种行为
真正的难点不在“怎么发已读”，而在“怎么让已读状态不卡、不丢、不乱序”。位图 + 脏标记 + 批量刷库 + Kafka 回写，这套组合拳缺一不可；任何环节想省事，上线后都会在凌晨三点被报警叫醒。
