I3.03.3offline action queue设计
离线期间的操作需排队并在恢复后处理
别名: 离线队列 · 恢复后同步 · pending queue · 待发送
概念解释
离线时人仍会写下、点赞、标已读。这些动作不能装成已经到达服务器，也不能直接丢弃。它们进入一条离线操作队列（offline action queue），连接恢复后再按序处理。队列是状态，不是日志：每一项都还欠一次真实写入，界面要能回答「排了几件、现在轮到谁」。
这条管的是「先收下、后送达」这条时间缝。本地是否被当成权威副本、冲突怎么合并，是另一套架构问题。没有队列，离线可写只是把输入吞进真空。
机制
断网把一次写入拆成两段：本地接受意图，和远端兑现意图。中间必须有一个耐久的容器，否则进程被杀、用户离开、系统回收内存，意图就蒸发。容器还要有序：先写的评论不能被后写的「删除这篇」抢先执行，否则恢复后的世界与用户的故事不一致。
恢复不是自动成功。队列开始排水时，每一项都可能被拒绝（权限变了、对象没了、配额满了）。所以「处理」包含确认、失败和重试，而不是把队列当焚化炉一烧了之。界面若只在恢复时闪一句「正在同步」然后清空列表，人无法核对应兑现的是否都兑现了。队列在排空之前必须可查。
边界
纯本地对象（未分享的草稿、只存在于这台设备的清单）不需要出站队列，写磁盘就是兑现。只读离线没有可排的写入。支付、对外发送、不可撤回的提交不应进这条「稍后处理」的队列——它们在离线时就该被挡在范围之外，而不是假装收下。队列过长（旅行一周后的几百次编辑）排空会变成一场冲突爆发，这时需要的是恢复预览而不是默默重放；那是长期离线的问题，不能靠把队列做大来假装已经处理。系统在恢复瞬间若同时灌入大量下行更新，队列排水要让得出路，否则上行意图被下行覆盖，排队等于白排。
怎么落地
- 离线写入一律进可持久化队列，杀死进程再打开，队列还在。
- 每项有可见身份：待发送、发送中、失败。恢复后按原顺序处理，失败项停在原位而不是消失。
- 给出队列入口：至少能看到条数和失败项，不要只在状态栏写「同步中」。
- 验证：断网后写两条评论、改一个标题，强杀应用再打开。两条评论和标题修改都应还在并标为待发送。恢复网络后它们应依次成为已送达；人为让第二条失败，第一条须仍成功，第二条须留在失败态可重试，而不是三条一起蒸发。