#草稿与同步

#设计意图

编辑环境中存在一个天然矛盾：用户希望内容「随时保存，永不丢失」，但网络可能不稳定，服务器可能暂时不可用。mdocs 用本地优先 + 按需发布的草稿机制来解决这个问题。

#架构

用户编辑
    │
    ▼
Lexical 编辑器（富文本）
    │
    ├── 自动保存（1000ms 防抖）──────────────────┐
    │       │                                    │
    │       ▼                                    │
    │   IndexedDB（浏览器本地数据库）               │
    │   存储：正文 + 开编 commit（localBaseCommitId）│
    │                                              │
    ├── 自动发布（空闲 30 秒后）───────────────────┤
    │       │  （每 10 秒扫描一次）                  │
    │       ▼                                    │
    │   后端 API（更新正文 + 提交图）              │
    │                                              │
    ├── 手动「发布」──────────────────────────────┤
    │                                              │
    └── 失焦 / 切换标签页 ────────────────────────┘
             立即保存当前内容

#本地数据分工（v0.7.9+）

打开文档时：一定会请求服务器更新 meta；正文则 有草稿读草稿、无草稿读服务器，二者互斥，不会把两套正文混在一个对象里。

#三层保存策略

补充说明：

• 首次编辑时才创建草稿（不是打开文档就创建）。
• 首次落盘会记录 localBaseCommitId（开编时服务端 head）。
• 后续自动保存只更新正文和标题，不重置开编基准。

#发布流程

#自动发布（可选）

在 设置 中开启「自动同步至云端」后：

• 每 10 秒扫描 IndexedDB；
• 某篇草稿 超过 30 秒 没有新的自动保存 → 尝试发布。

#手动发布

1. 点击「发布」
2. 编辑器内容序列化后 PUT 到服务器（带开编 commit 做版本校验）
3. 成功后：删除本地草稿 → 再 GET 拉取最新 → 更新界面 meta 与编辑器（与服务器对齐）

#无草稿也能发布

若打开后尚未触发自动保存（尚无 IndexedDB 草稿），仍可直接发布：内容以编辑器为准，版本号以当前 meta 中的 head 为准。

#发布失败

无论自动还是手动，失败时草稿一般仍保留在本地。

重新打开文档且服务端已有 headCommitId 时，会自动补写草稿的 localBaseCommitId 并清除「缺版本基准」类失败标记。

#断网场景

• 断网时：继续编辑，草稿在 IndexedDB
• 重新打开：有草稿则恢复草稿正文；meta 仍会从服务器 GET（需联网）

#拉取更新（Pull）

• 无未发布草稿：可拉取远端最新正文与 meta。
• 有未发布草稿：不覆盖式 pull，避免误盖本地副本。

#设计取舍

• 本地优先：编辑不依赖网络；恢复后自动或手动发布
• 发布后强制对齐：删草稿 + GET，减少「单用户自动发布后又冲突」的困惑
• IndexedDB：容量大、异步，不阻塞 UI