手机读过了，电脑为何又显示未读？

同一账号在手机读完消息，电脑上的未读提醒也应该消失。但两端同时操作时，旧请求可能晚到；直接覆盖阅读位置，就可能让已读消息重新变成未读。

项目用已读光标同步进度。光标描述某个会话读到了哪条消息、在什么时间，而各端再根据它批量更新本地消息和计数。

为什么不只同步一个未读数量？

数量描述结果，却没有说明哪些消息已经阅读。不同设备接收和补历史的时间不同，单独同步一个数字，很难与各自的消息集合对应。

同步阅读边界可以让本地重算哪些消息已读，也不必跨端逐条传布尔值。项目仍保留消息级阅读状态供存储和展示，但跨端进度由会话光标关联。

本人读到哪里、对方是否读过我发的消息、消息发送是否成功，也分别保存。它们影响不同界面，不能都塞进一个“成功”状态。

如果允许按到达顺序覆盖，读时间 2000 之后又收到旧值 1000，位置就会倒退。可以用服务端序号或版本确定先后；项目当前选择比较光标中的阅读时间。

新时间更大就接纳，旧时间更小就保留当前值。时间相同时，只在本地缺消息 ID、传入结果有 ID 时补上。当前时间为空、新值有效时可以接纳；新值没有时间，则不覆盖已有有效位置。

这里没有比较两个消息 ID 的字典序，因为 ID 未必代表消息顺序。这套方法也依赖各链路的时间可比较；同时间的精确边界、主动重置进度和更严格顺序，需要另行定义版本或序号。

项目存在群下私聊：一个成员可以在群甲的业务下和工作人员单独沟通，也可以在群乙下再聊。对象是同一人，业务范围却不同。

如果只按对象地址保存光标，读完群甲就可能清掉群乙的未读。项目因此把会话地址与来源群一起用于光标身份，历史请求、存储、分页、通知和计数也沿用同一范围。

没有来源群的主会话，表示只处理消息本身也不带来源群的那部分，而不是不筛选、取出该对象所有消息。Web 部分未读统计已区分这两种含义，其他查询和更新入口仍需保持一致。光标 key 写对了，并不会自动修正漏传范围的调用方。

页面与数据库可能各有一份状态。只写数据库，当前界面仍可能显示内存中的旧值；只改内存，刷新后又会从数据库恢复旧值。

项目的 Web 处理会批量更新数据库、修改内存消息状态，再刷新未读数。中间一步失败时，仍需要后续同步校准。