如何在WebSocket中实现消息的“已读/未读”状态实时更新实现方法【教程】-js教程-PHP中文网

WebSocket本身不提供“已读”语义，必须由业务层主动上报、后端状态维护（如位图存储）、客户端联动（IntersectionObserver监听可视区域）共同闭环，避免误判与高并发瓶颈。

如何在websocket中实现消息的“已读/未读”状态实时更新实现方法【教程】

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）是更优解：

一条消息最多支持 1024 个接收者 → 用 128 字节字符串（CHAR(128)）存所有用户已读位，第 N 位为 1 表示 UID=N 的用户已读
内存中用 Swoole\Table 或 ConcurrentHashMap 管理脏位图，避免每次操作都查 DB
更新位图用原子操作：bits[n / 8] |= (1 ，查状态用 (bits[n / 8] >> (n % 8)) & 1
批量落库：定时器每 3 秒扫描所有脏位图，拼成单条 INSERT ... ON DUPLICATE KEY UPDATE 执行

WebSocket 怎么把已读变化实时推给发送方

已读回执不是单向写 DB，它要立刻让发送方感知到——这需要服务端维护“谁发了哪条消息”这个映射关系：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

消息入库时记录 sender_id 和 msg_id，并缓存在 ConcurrentMap 中（msg_id → sender_id）
当某用户 A 标记消息 M 已读，后端查出发送者 B，再通过 sessionMap.get(B) 找到 B 的 WebSocket Session
推送格式统一为 { "type": "READ_ACK", "messageId": "m789", "readerId": "u123", "timestamp": 1716625680 }，避免前端再解析
如果发送方不在线，这条 ACK 不丢弃，而是进 Kafka Topic topic_message_readStatus_writeBack，等其重连后从 Redis 未读队列里补推