已读回执必须由客户端主动上报，服务端无法自动感知；需通过消息id和会话id校验权限与幂等性；用redis维护uid连接映射实现实时同步；未读数应冗余存储并原子更新；离线消息需基于唯一message_id批量查已读状态。
已读回执必须依赖客户端主动上报
Workerman 本身不提供“消息已读”状态的自动感知能力，因为 HTTP 或 WebSocket 连接是无状态的，服务端无法知道用户是否真的看了某条消息。飞书、钉钉的已读功能本质是：客户端在消息进入前台、滚动到可视区域、或用户点击/展开消息时，主动发一条 markAsRead 请求（例如 POST /api/messages/read）到服务端，由服务端更新数据库中该消息的 read_at 字段。
常见错误现象：
— 直接监听 WebSocket onMessage 就认为“收到即已读”，这会导致未展示就标记为已读；
— 在服务端定时扫描“超时未读消息”并自动设为已读，这违背产品逻辑，也容易误判。
实操建议：
— 客户端需明确区分“接收成功”和“用户已阅”，后者必须带消息 ID 和会话 ID 上报；
— 服务端接口（如 handleMarkAsRead）应校验用户权限（当前登录人能否操作该会话）、消息归属（该消息确属该用户单聊）、幂等性（重复上报只更新一次 read_at）；
— 数据库表建议包含字段：message_id、from_uid、to_uid、read_at（NULL 表示未读）。
用 Workerman WebSocket 管理在线状态与会话路由
单聊场景下，“已读未读”状态要实时同步给对方（比如对方看到“已读”标签），这就需要服务端能快速定位目标用户的 WebSocket 连接，并推送状态变更。Workerman 的 $connection->send() 只能发给当前连接，所以必须维护一个 UID → Connection 的映射关系。
常见错误现象：
— 把所有连接存进全局数组但没加锁，高并发时出现覆盖或空指针；
— 使用 $_SESSION 或文件存储连接映射，导致多进程间不同步；
— 每次都查数据库找对方在线状态，性能差且不准（连接断开但 DB 未及时更新）。
实操建议：
— 在 onConnect 中用 Worker::$connections 或 Redis（推荐）存 uid => connection_id 映射，Key 形如 workerman:online:uid:{uid}；
— 在 onClose 中立刻从映射里删掉该 uid（Redis 可设 5 秒过期兜底）；
— 当 A 标记某条消息已读，服务端查出 B 的 connection_id，再通过 ConnectionManager::getConnectionById($id) 获取连接并 send() 推送 {"type":"read_receipt","msg_id":"xxx"}；
— 不要用 foreach ($worker->connections as $conn) 全局遍历，效率低且易漏。
飞书最新版全局新增 HTML 文件预览，云盘 / 会话 / 文档内上传的.html 文件可切换**预览视图 / 代码视图**，无需下载即可查看页面渲染效果；多维表格配套优化 AI 交互响应速度，仪表盘图表加载、批量数据运算性能大幅提升；全端消息、文档、多维表格滚动卡顿修复，大数据表千行数据筛选不卡顿；会议、审批、知识库同步小幅体验优化，AI 助手问答准确率提升。
未读数统计不能只靠 COUNT(*)
用户打开聊天窗口时，前端通常要显示“你有 3 条未读消息”。如果每次请求都 SELECT COUNT(*) FROM messages WHERE to_uid = ? AND read_at IS NULL，在消息量大、会话频繁时会拖慢响应，尤其当用户有上百个会话时更明显。
实操建议：
— 单聊未读数建议冗余到用户维度，建一张 user_unread_count 表，字段含 uid、target_uid、count、updated_at；
— 消息插入时（发送方调用 sendMessage），立即对 target_uid 的计数器 +1（Redis INCR workerman:unread:{target_uid}:{from_uid} 更快）；
— 用户标记已读时，对应计数器 -1，并将结果同步写回 DB（避免 Redis 故障丢失）；
— 前端拉取会话列表时，直接查这张表或 Redis，O(1) 返回；
— 注意事务边界：消息落库成功后，再更新未读数，否则会出现“消息丢了但未读数减了”的错乱。
离线消息 + 已读状态的时序一致性最难处理
用户 A 发消息给 B，B 当时离线；B 上线后拉取离线消息，但此时 A 已经把那条消息标记为“已读”——服务端怎么知道这条离线消息对 B 来说其实是“已读”？关键在于：已读状态必须绑定具体消息，而不是会话。
实操建议：
— 所有消息入库时生成唯一 message_id（UUID 或雪花 ID），已读记录也以 message_id 为主键；
— B 上线拉取消息时，服务端查出消息列表后，再批量查询这些 message_id 是否已在 read_receipts 表中存在（WHERE message_id IN (…)），返回时带上 "read": true/false 字段；
— 不要等 B 拉取完再逐条上报已读，那样会多一次 RTT；
— 如果使用 Redis 存已读状态，可用 SET workerman:read:{message_id} 或 HSET workerman:reads:{uid} {message_id} 1，后者便于按用户查已读集合。
这个环节最容易被忽略的是消息 ID 的全局唯一性和生命周期管理——一旦 ID 重复或被回收，已读状态就会错挂到其他消息上。
