自动保存适合持续编辑、需要随时续写的内容；手动保存适合用户希望确认一组更改后再统一提交的配置。选择的关键，是先分清“保存草稿”和“让修改立即生效”。文章自动保存到草稿箱，并不代表已经发布；价格设置写入数据库，也不意味着应当在用户还没确认时就对外生效。
保存交互最容易让人不安的时刻，往往发生在用户已经写了很多内容之后：右上角还显示“保存中”，网络突然断开，他不知道现在关掉页面会不会丢。设计要回答这个具体问题，而不能仅用一个自动保存开关代替规则。
先决定保存的是草稿，还是生效配置
把保存与发布分开，能够保留编辑的连续性，也给重要决策留下确认点。例如知识库文章可以自动保存草稿，点击“发布”后读者才看到新内容。相反，通知偏好中的一个低影响开关，用户可能期望修改后立即生效。两种任务不应共用模糊的“保存成功”。
| 编辑情境 | 可考虑的保存方式 | 需要说清的边界 |
|---|---|---|
| 长文章、笔记、描述内容 | 自动保存草稿，另设发布动作 | 草稿与已发布版本分别是谁可见 |
| 需要一起生效的一组配置 | 统一保存或应用更改 | 保存前后哪些规则生效 |
| 低影响的单项偏好 | 修改后保存，并反馈结果 | 失败时回退旧值，还是保留待重试新值 |
| 金额、权限、外部通知等重要变更 | 明确确认与生效步骤 | 已经发生的外部结果是否可撤回 |
这张表提供判断方向，不替代业务决策。即使采用自动保存，也可以只保存编辑草稿，把“应用到全部成员”留为单独动作。界面上应使用“草稿已保存”“设置已生效”等与真实结果对应的文字。
如果团队讨论的是设计文件的历史版本、操作日志和回滚节点，可另看原型与设计的版本留痕方法。这里要解决的是你正在设计的业务产品怎样保存用户的编辑内容。
不要在发出请求时就显示“已保存”
用户修改了内容、浏览器发出了请求、服务端确认保存，是三个不同节点。保存提示应反映当前这份内容的真实状态，而不是只证明按钮被点过。
以一篇标题为“报销材料说明”的知识库文章为例，用户刚修改了第二段，尚未发布。下面的状态命名可以直接用于原型与交互说明；时间“14:32”是示例显示，不代表系统应固定每分钟保存。
| 发生的事情 | 建议反馈 | 当前内容的处理 |
|---|---|---|
| 出现尚未提交的更改 | 有未保存的更改 | 保留编辑内容，等待保存条件 |
| 正在请求保存 | 正在保存草稿 | 明确是否仍可继续编辑 |
| 当前内容获得服务端确认 | 草稿已保存 · 14:32 | 说明保存位置与可恢复范围 |
| 请求明确失败 | 草稿保存失败，请重试 | 保留当前输入，不假装已同步 |
| 结果尚不确定 | 正在确认保存结果 | 先查询状态，避免重复版本覆盖 |
| 发现较新版本 | 此文章已有更新，请比较后继续 | 保留本地修改，避免静默覆盖 |
若前一次保存尚未返回，用户又修改了内容，旧响应不能把最新内容标成已保存。原型可以用“上一批更改已保存，仍有新更改待保存”表达这类情况；实现时需要研发识别请求对应的版本，不能仅凭最后收到一个成功响应判断。
自动保存的触发时机，要配合编辑节奏
常见触发包括停止输入一段时间、离开字段、完成一次明确编辑动作，或定期保存。没有一个间隔适合所有产品。输入文字、拖动大量对象、批量调整设置对系统和用户的影响不同，应结合保存成本、恢复要求与实际操作评估。
设计说明可以先写触发事件和状态，而不抢先指定实现细节。例如：“连续编辑时保留待保存状态；用户短暂停止后触发草稿保存；仍有更改时继续安排后续保存。”如果用户必须主动操作，按钮就应一直容易找到，不能让滚动到页面底部成为保存长内容的唯一方式。
Shopify的保存栏设计提供了一个清晰参考：有未保存信息时显示保存与丢弃操作，离开前处理尚未保存的更改。这是交互模式的参考，不表示所有表单都需要相同的固定保存栏。
保存失败后，保留文字只是第一步
“内容已保留”必须说明保留在哪里。如果只保留在当前页面内存中，刷新可能丢失；如果写入当前浏览器的本地草稿，也不代表另一台设备能恢复。只有已被服务端确认的草稿，才可以按产品实际能力说明跨设备继续编辑。
假设“报销材料说明”保存时断网，本例可以显示：“暂时无法保存到服务器，请保持页面打开，连接恢复后重试。”如果实现确实支持本地草稿，再增加“已暂存于此浏览器”。未经实现与验证，不应为了安抚用户就写“内容绝不会丢失”。
失败原因不同，动作也要不同。网络恢复可以重试；登录过期需要重新确认身份，同时尽量保留当前编辑；权限被撤回则不能无限重试，应该解释无法继续写入，并提供复制自己所写内容等符合权限规则的处理方式。
“重试”期间应避免并行发出多个互相覆盖的保存请求。如果采用自动重试，也要让用户知道仍在处理；持续失败后给出稳定可见的提醒，不要每次重试都弹一个新的Toast。
离开确认能提醒用户，但不能保证每次都出现
在应用内部切换页面时，可以根据未保存状态提示“保存后离开”“放弃本次更改”“继续编辑”。如果当前无法保存，就不能让“保存后离开”点击后直接跳转。已保存草稿但尚未发布，也不应被说成“更改会丢失”；提示要与实际后果匹配。
关闭标签、刷新浏览器和手机切到其他应用，具有不同的触发条件。MDN对beforeunload的说明指出，离开确认在移动场景中并不总会触发，而且浏览器弹窗文字不能由网页任意指定。因此，不能把“关闭时弹确认”当成保存机制；草稿保护需要在编辑期间完成。
有未保存更改才提醒，才能减少无意义打断。用户没有修改内容、已经成功保存，或只是查看一篇文章时，不应每次离开都问“确定退出吗”。如果填写内容又恢复成原值，团队也要确认是否仍算有更改，避免保存栏永远无法消失。
恢复草稿时，别悄悄盖掉较新的内容
重新打开编辑页，可能同时存在浏览器里的旧草稿和服务端较新的版本。直接恢复本地草稿，可能覆盖另一位同事已经确认的修改。可先显示草稿的对象、保存时间及来源，允许查看差异，再决定继续编辑哪一份。
对于本例，恢复提示可以写：“此浏览器保留了14:32的未同步草稿；服务器版本更新于14:40。”按钮使用“查看草稿”和“使用服务器版本”，不要用含糊的“恢复”“取消”让人猜测哪一份会被丢弃。发生冲突时，保留双方内容或允许复制，比直接选择一个最后写入值更便于用户判断。
把保存策略做成一条能走通的编辑路径
使用墨刀原型时，可以保留同一篇“报销材料说明”，分别做未修改、待保存、保存中、已保存、失败和恢复选择页。连接“编辑第二段→保存失败→重试成功→离开→重新打开”的路径，重点观察每次提示能否让读者判断内容现在在哪里。
再增加一条分支：保存中继续输入一句话。收到旧保存成功结果后，最新一句仍应显示待保存。最后用两个不同更新时间测试恢复选择，检查按钮是否对应正确内容。演示用于确认规则；真正的本地持久化、服务端写入和版本冲突仍要由研发实现并验证。
一份可以带给团队的保存说明，应写明保存对象、触发时机、服务端确认条件、编辑中继续输入的处理、失败保留位置、离开策略、恢复范围和冲突规则。先把这些问题说清，保存按钮与状态提示就有了共同依据。
