自动保存已经成了在线编辑器的标配。
光标一停，内容自动落库；网络断了，本地草稿兜底；切换页面前，再把最后一批改动冲出去。理论上，用户已经不需要再碰“保存”按钮了。
我一开始也是这么想的。
所以当有人问“能不能让我手动保存一下”时，我的第一反应是：内容不是已经自动保存了吗？再做一个 Ctrl+S，除了照顾旧习惯，好像没有多少实际价值。
后来真正把历史版本、多端编辑、AI 改写和格式转换放进同一套笔记系统后，我才意识到，用户想要的根本不是“再保存一次”。
他真正想表达的是：
我现在很认可这个状态，后面不管怎么改，都希望还能回到这里。
自动保存保护的是“最新内容别丢”；手动保存版本保护的是“这个关键节点别丢”。
两者看起来都叫保存，解决的却不是同一个问题。
一、自动保存解决了丢失焦虑，却没有解决修改焦虑
自动保存最直接的价值，是让用户不用担心忘记按保存。
连续输入时，系统在后台把改动合并后写入服务端；弱网或断网时，本地草稿先托住；切换笔记、离开页面或主动保存时，再立即清空等待中的保存队列。
这套机制解决的是：
- 浏览器突然崩了，刚写的内容还在不在；
- 用户切走页面，最后几句话有没有落库；
- 网络短暂中断后，能不能继续补写；
- 连续输入时，服务端会不会被每个按键打一次请求。
但它没有回答另一个问题：
我大改之前的那个版本，还能不能准确找回来？
这个问题在下面这些场景里特别明显：
- 一篇长文刚完成结构，准备重写其中三节；
- 准备把富文本切成 Markdown；
- 让 AI 大幅润色整篇内容；
- 在电脑和手机之间来回编辑；
- 手绘内容即将进行一次大范围擦除或重排。
用户担心的不是“刚才那句话会不会丢”，而是“接下来改坏了怎么办”。
这是一种完全不同的心理压力。
自动保存越及时，甚至越容易加重这种压力：每一次错误修改也会被快速保存成最新状态。
所以“永远保存最新”并不天然等于“用户永远安心”。
二、一套真正可靠的保存系统，其实至少有三层
后来我把保存重新拆成了三层。
第一层：本地草稿
它负责对抗最短时间尺度的意外。
比如页面刷新、浏览器异常、网络瞬断。用户输入后，不必等待服务端请求完成，本地先保存一份草稿。
这层追求的是快，允许内容比较新，但它不是长期事实源。
第二层：服务端最新状态
它负责回答：这篇笔记现在是什么样。
在当前实现里，文字笔记连续输入会经过约 1.5 秒的合并窗口再保存；手绘笔记因为场景序列化更重，保存窗口放宽到约 3 秒。离开页面、切换笔记和显式保存时，则会立即 flush，不再等待定时器。
这一层追求的是持续、稳定、跨设备可读。
第三层：明确的还原点
它负责回答：用户未来想回到哪个状态。
自动历史会留下部分旧版本，但它需要去重、合并和控制数量，否则用户写十分钟，版本列表就可能出现几十甚至上百条记录。
因此，文字笔记的自动历史按时间窗口合并，最多保留一定数量；手绘场景更大，合并窗口和保留上限更保守。
手动版本则不同。
当用户按下 Ctrl+S，他不是在说“请再写一次数据库”，而是在说：
把当前已经落库的状态，明确标成一个可以回来找的节点。
这也是为什么手动版本不应该被自动历史的时间合并规则吞掉。
三、Ctrl+S 不能直接“截一份数据库快照”
给编辑器加一个快捷键并不难。
真正容易写错的地方，是执行顺序。
假设用户刚刚写完最后一段，自动保存的 1.5 秒计时器还没触发，这时立刻按 Ctrl+S。
如果服务端直接对数据库当前内容创建版本，那么保存下来的其实是上一版，不是用户眼前看到的内容。
界面会提示“版本已保存”，用户以后恢复时却发现最后一段不在里面。这比没有手动版本更糟，因为系统给了一个错误的确定感。
所以现在的流程分成两步：
- 先立即保存当前编辑内容，清空等待中的自动保存；
- 只有服务端确认成功后，才基于当前 revision 创建手动还原点。
这个拆分很重要。
“保存最新内容”和“标记当前版本”是两个动作：
- 第一个动作修改笔记本身；
- 第二个动作只创建一个历史节点。
把它们混成一个模糊的“保存”，后面遇到弱网、冲突和重试时很难判断到底成功了哪一步。
四、为什么手动版本一定要带 revision
如果笔记只会在一个页面里编辑，事情会简单很多。
但一旦支持多标签页、多设备，或者服务端有其他写入入口，用户按下 Ctrl+S 时，数据库里的内容可能已经发生变化。
例如：
- 电脑端打开的是 revision 12；
- 手机端已经把同一篇笔记保存成 revision 13；
- 电脑端还不知道这次变化，此时用户按下 Ctrl+S。
服务端不能假装一切正常。
当前链路会把客户端看到的 revision 一起提交。服务端锁定笔记后，重新读取真实 revision：
- 两者一致，才创建手动版本；
- 两者不一致，返回版本冲突，让用户先处理云端和本地内容。
为什么不能简单把云端当前内容存成版本，再告诉用户成功？
因为用户按下 Ctrl+S 时，认可的是他眼前的内容，而不是服务器上另一个设备刚写入的内容。
如果系统悄悄保存了别的状态，按钮的语义就被破坏了。
所以 revision 不只是并发控制字段，它还在保护用户意图：
你要保存的，必须真的是你此刻看到并认可的那个版本。
五、自动历史要“克制”，手动版本要“明确”
历史版本系统很容易走向两个极端。
一种是几乎不留历史，真正出问题时没有可恢复内容。
另一种是任何自动保存都创建一条历史，结果版本列表像日志一样密密麻麻，用户根本不知道该选哪一条。
我更倾向于让两种历史承担不同角色。
自动历史负责兜底
它不需要记录每一次输入，只需要在持续编辑过程中，周期性留下可恢复状态。
因此它可以：
- 内容没变化时不新增；
- 短时间内连续编辑时合并；
- 超过保留上限后删除最旧版本。
它的目标是“出了意外还能大致回去”。
手动版本负责表达意图
它不受自动合并窗口影响。
用户主动保存一次，就留下一个明确节点。即使刚刚已经产生自动历史，手动版本仍然应该被单独保留。
在数据层，手动版本也应该拥有独立的来源标识；历史界面最好把这种来源明确展示出来，否则用户主动标记关键节点的意义又会被隐藏。
它的目标是“我知道自己为什么要回到这里”。
这两个系统放在一起，版本列表才既不会太吵，也不会失去关键节点。
六、恢复版本之前，也要先留一颗“后悔药”
版本恢复还有一个很容易忽略的问题。
用户从 revision 20 恢复到 revision 12，并不代表 revision 20 就应该从此消失。
他可能恢复后才发现：
- 选错了版本；
- 旧版本缺少后来新增的重要段落；
- 只想参考旧内容，而不是彻底覆盖当前内容。
因此，恢复操作不应该只是“读取旧版本，然后覆盖当前笔记”。
更安全的流程是：
- 锁定当前笔记，确认 revision 没有变化；
- 强制把恢复前的当前状态存成一条历史；
- 再用目标版本覆盖正文和类型；
- revision 继续向前增长，而不是倒退到旧数字。
这样，“恢复”本身也可以被撤销。
历史版本不再是一条只能往回跳的时间线，而是一套可安全试错的机制。
七、保存状态必须诚实，不能只有“已保存”一种文案
自动保存做得再完善，也不能把所有情况都包装成“已保存”。
至少应该区分：
- 等待保存；
- 正在保存；
- 已保存；
- 离线；
- 保存失败；
- 版本冲突。
用户不需要理解保存队列、revision 和事务，但他需要知道当前状态是否可信。
尤其是在离线和冲突场景中，最危险的不是暂时保存不了，而是界面仍然让用户以为已经完成。
Ctrl+S 也需要遵守这一点：
- Windows / Linux 使用 Ctrl+S；
- macOS 使用 Command+S；
- 编辑器要阻止浏览器默认的“保存网页”；
- 内容保存失败时，不能继续创建版本；
- 版本创建失败时，也不能把“笔记已保存”和“还原点已创建”混成同一个成功提示。
这些细节看起来很琐碎，却决定了用户是否敢在重要内容上真正依赖这套系统。
八、不是所有编辑器都需要 Ctrl+S
如果内容很短、可随时重建，自动保存通常已经足够。
但下面这些产品，我认为手动还原点很有价值：
- 长文写作；
- 产品文档和项目方案；
- 研究笔记；
- AI 辅助改写；
- 结构化知识库；
- 手绘和复杂场景编辑器；
- 多端、多人或多入口编辑。
判断标准不是用户有没有按快捷键的习惯，而是：
后续修改的风险，是否大到用户会想明确保留当前状态。
只要答案是肯定的，手动版本就不是复古功能，而是风险控制功能。
九、最后整理成一份实现清单
如果要在自动保存编辑器里增加手动版本，我会至少检查这些问题：
- Ctrl+S 是否先 flush 当前未保存内容；
- 手动版本是否与自动历史分开；
- 是否不受自动版本的时间合并窗口影响；
- 创建版本时是否携带 expected revision；
- 服务端是否锁定权威记录后再判断冲突；
- 离线和保存失败时是否停止后续动作；
- 历史列表是否能区分自动、手动、格式转换和恢复前快照；
- 恢复前是否先保存当前状态；
- 恢复后 revision 是否继续递增；
- 版本数量是否有清晰的保留上限。
这些规则不复杂，但缺一两条，用户在真正需要恢复时就可能遇到最糟糕的情况：
界面说保存成功，实际保存的却不是他以为的那个状态。
结语
自动保存让“忘记保存”逐渐成为过去式，这当然是一件好事。
但它并没有消灭用户对控制感的需要。
用户按下 Ctrl+S，不一定是在怀疑系统有没有保存；很多时候，他只是想给当前工作插一面旗子：
到这里为止，我是满意的。
所以我最终又把 Ctrl+S 加了回来。
不是为了让用户承担保存责任，而是为了让他有权决定：哪些瞬间值得被系统认真记住。
仓库开源仓库：
