核心矛盾是多端并发编辑导致的覆盖风险，必须用“版本化文档+元操作日志”替代单文档覆盖：主文档存合并结果，draft_ops集合存不可变操作记录，按设备隔离、crdt消解冲突，并通过本地队列与幂等重试保障离线同步可靠性。
多端同步草稿箱不是“加个 timestamp 就行”，核心矛盾在于：不同设备可能同时修改同一份草稿，且网络延迟、离线编辑、冲突检测都得在文档模型层兜住。直接用单个 drafts 集合 + _id 做唯一标识，必然导致最后保存者覆盖他人修改——这不是应用逻辑能绕开的问题，必须靠模型设计提前隔离风险。
用“版本化文档 + 元操作日志”替代单文档覆盖
别把草稿当成一个可随意 updateOne 的文档。每个草稿应拆成两部分：主文档（只存最终合并结果）+ 操作日志集合（draft_ops）。每次编辑（哪怕只是光标移动后输入一个字）都生成一条不可变的 { op: "insert", path: ["content", 12], value: "a", timestamp, deviceId } 记录。
- 主文档
drafts只由服务端定时或提交时聚合生成，避免客户端直写 -
draft_ops按{ draftId: 1, timestamp: 1 }建复合索引，保证按序拉取效率 - 离线时所有操作本地暂存，上线后批量插入
draft_ops，不依赖事务一致性（WiredTiger 单文档原子性已足够） - 服务端聚合时用 CRDT（如 LWW-Element-Set）做冲突消解，而非简单“以最新时间为准”
设备维度隔离 + 最终一致性校验字段
用户在手机端改标题、在 iPad 端改正文、在桌面端调格式——这些操作若混在同一条日志流里，合并顺序错乱就会丢内容。必须让每台设备有独立操作通道。
- 每个
draft_ops文档必须带deviceId字段（非 session ID，是设备指纹级唯一标识） - 主文档
drafts中增加lastSyncAt: { mobile: ISODate(...), web: ISODate(...), tablet: ISODate(...) }对象，记录各端最后成功同步时间点 - 客户端拉取增量日志时，传自己上次同步的
lastSyncAt[myDevice]，服务端只返回该时间之后的本设备操作 - 避免用
updatedAt全局字段——它无法区分“谁改的”和“改了哪部分”
避免 GridFS 存草稿快照，用分片集合存历史版本
有人想把每次自动保存的完整草稿快照用 GridFS 存，这是典型误用。GridFS 是为大文件（>16MB）设计的，而草稿文本即使含 base64 图片也很少超几 MB；更关键的是，GridFS 的 fs.files 和 fs.chunks 无法高效做时间范围查询或按设备过滤。
- 正确做法：建分片集合
draft_revisions，按draftId分片，每条文档存一次快照：{ _id, draftId, deviceId, contentHash, content: "...", createdAt } - 只保留最近 5 次快照（按
createdAt），用 TTL 索引自动清理：db.draft_revisions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 60 * 60 * 24 * 7 }) -
contentHash用 SHA-256，用于快速判断两次快照内容是否真有差异，避免无意义写入 - 不存原始二进制，所有文本类内容保持 UTF-8 字符串，确保可被
$text索引搜索
客户端必须实现本地操作队列与幂等重试
模型再健壮，客户端没处理好网络抖动也会导致重复日志或丢失操作。服务端不做“去重”，而是靠客户端保证每条操作的 opId 全局唯一（UUID v4 + 时间戳前缀）。
- 所有编辑操作先入本地 IndexedDB 队列，状态为
pending - 发往服务端成功后，更新队列中该条状态为
synced；失败则按指数退避重试，直到成功或超时（如 24 小时） - 服务端接口必须接受
opId并做upsert，避免重复插入相同操作（{ opId: 1, unique: true }） - APP 启动时扫描本地队列，对
pending操作补发，不依赖“上次退出时是否连网”
真正难的不是存数据，是让“多个离线设备各自编辑、再连网同步”这件事，在 MongoDB 的文档模型约束下依然可预测、可追溯、可回滚。嵌入式数组存操作日志、分片集合管快照、设备维度切分离线状态——这些不是炫技，而是把分布式系统里的 CAP 权衡，提前压进数据结构里。
