Go中实现消息已读回执需构建可验证、可追溯、不阻塞的双向状态同步机制，接收方须在用户真正查看消息后主动触发，服务端须基于clientMsgID关联并幂等处理回执。
Go 里实现消息已读回执，核心不是“发个通知”，而是构建可验证、可追溯、不阻塞的双向状态同步机制。直接在 Send 后调用 ackRead 是错的——它掩盖了离线、重连、重复投递等真实问题。
如何让接收方可靠触发已读回执
已读回执必须由接收方在「用户真正看到消息」后主动发起，不能依赖 SDK 自动发送（多数 IM SDK 不自动发已读）。常见错误是把回执逻辑写在消息入库后就立刻调用，结果用户还没打开聊天窗口，回执已发出去。
- Web 端：监听消息 DOM 渲染完成 + 滚动到可视区域（用
IntersectionObserver），再触发sendReadAck(messageID) - 移动端：在
onMessageReceived后延时 500ms（防快速滑动未读），且仅当当前会话页处于前台 + 消息在屏幕内才发回执 - 服务端中转场景（如群消息）：接收方收到后不立即 ack，而是先落库标记
status = 'received'，等业务层确认阅读行为（如点击展开、停留超 2s）再更新为'read'并推送回执
发送方怎么安全接收并处理回执
回执本质是一条特殊类型的消息，必须和原始消息通过 messageID 关联。别用时间戳或顺序号匹配——网络抖动会导致乱序。
- 原始消息发送时，务必设置唯一、稳定、客户端生成的
clientMsgID（如uuid.NewString()），并透传给服务端存入消息表 - 回执消息体必须携带该
clientMsgID，服务端收到后查库定位原始消息，更新read_at字段 - HTTP 接口接收回执时，响应必须是
200 OK且无 body；失败时不重试，由客户端按指数退避重发（最多 3 次） - 避免在 HTTP handler 中直接更新数据库——用异步 job（如
chan ReadAckJob）消费，防止慢 SQL 拖垮整个回执通道
群聊已读回执的三个硬约束
群聊回执比单聊复杂得多，不是加个 flag 就能跑通。
立即学习“go语言免费学习笔记（深入）”；
- 必须在发送群消息时显式设置
allowGroupAck: true（或对应 SDK 的setIsNeedGroupAck(true)），否则服务端不会要求成员返回回执 - 群成员收到消息后，需调用专用方法（如
ackGroupMessageRead(groupID, messageID)），不能复用单聊的sendReadAck，协议字段不同 - 查询已读详情（如谁没读）必须走服务端 API，如
GET /v1/groups/{gid}/messages/{mid}/reads，前端绝不能靠本地缓存拼凑结果——群成员进出频繁，状态极易过期
最容易被忽略的是回执的幂等性设计：同一个 clientMsgID 的回执可能因重连、重发被多次送达。服务端必须用 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或 REPLACE INTO（MySQL）保证只记录一次已读时间，而不是简单 UPDATE。否则一次误触，就会把“未读”覆盖成“已读”。
