离线期间的编辑需在重连后可被合并而非丢弃
别名: 离线优先 · 断线编辑保留 · 重连合并
概念解释
用户在断网期间的编辑——地铁里改的段落、飞行模式下调的表格、信号死角里写的批注——必须在重连后作为待合并的修改进入系统，而不是因为「离线时的状态不作数」被丢弃。这条要求把离线从「功能故障状态」变成「一种正常的操作模式」：编辑权不依赖连接，连接只负责传播。判据是用户层面的：断网期间做的任何有效操作，重连后要么出现在结果里、要么出现在待处理的冲突里，唯独不能无声蒸发。
机制
丢弃离线编辑的系统实际上把「连接」当成了操作的合法性来源：指令没有实时送达服务器，就视为从未发生。这个模型在桌面宽带时代勉强成立（断网罕见），在移动场景里彻底破产——通勤、差旅、信号死角是日常，若每次断网都在赌编辑会不会丢，用户只能养成本地备份的自保习惯，协作工具的核心价值（放心地把工作放进来）随之瓦解。离线可合并的模型把合法性交还给操作本身：编辑先落本地队列，附带对象、时间与意图信息；重连后队列回放，与服务器状态合并。合并的机制（自动融合或冲突呈现）是并发编辑的老问题；离线场景真正的增量在于队列的两头：断网瞬间要无缝切入本地模式（不弹错误、不锁功能），重连瞬间要让用户知道「你有 N 条修改正在合并、结果如何」。离线时间越长，他人改动越多，冲突概率越高，所以离线编辑的元数据（何时改的、基于哪一版改的）必须完整保留——它们是重连后判断「还能不能自动合并」的依据。
边界
离线可合并不是所有协作类型都平等适用。文本与自由画布的离线编辑合并成熟（细粒度、语义宽容）；强竞争性操作（抢占名额、扣减库存）不能离线执行——本地「成功」在重连时可能已被他人取走，这类操作离线时只能排队待确认而不能给成功反馈；实时性强的协作（共驾演示、协同操作）离线即失去意义，正确的离线行为是暂停与告知，不是继续接受操作。离线的时长上限也随冲突密度变化：同事密集共写的文档离线半天，重连冲突可能多到合并成本超过重写；低冲突场景（个人笔记、低频共享）离线几天无压力。
怎么落地
- 断网检测触发时静默切换本地模式：继续可编辑，界面常驻「离线中，修改将稍后同步」状态。
- 本地操作队列保存完整元数据（目标对象、基准版本、时间戳），为重连合并与冲突判定提供依据。
- 重连后自动回放合并，向用户报告结果：成功合并了什么、产生了哪些冲突（进入冲突处理流程，绝不静默择一）。
- 强竞争性操作在离线时标记为「待确认」，不显示为已完成。
- 验证：断网时长从 1 分钟到 1 天的梯度测试里执行各类操作，重连后逐项核对：每条操作要么在结果中、要么在冲突列表中；出现第三种结局（消失）即为事故级缺陷。