未保存就离开页面怎么办？草稿、自动保存与退出提示设计

活动名称、报名说明和参与条件刚填完，用户点击左上角返回，页面却直接关闭了。另一种同样令人困惑的体验是：什么也没改，只是打开设置看了一眼，离开时仍被问“是否放弃修改”。未保存退出提示的关键，不是给所有返回按钮加弹窗，而是准确判断哪些内容尚未保留、离开会失去什么。

以一份活动设置表为例：运营人员先编辑草稿，再单独发布活动。保存草稿不等于公开发布，返回列表也不意味着放弃已经保存的内容。先把这些动作分清，自动保存和离开保护才不会互相矛盾。

可以先用同一份表单串联“已修改—保存中—保存失败—离开确认”几张状态稿，再通过原型编辑与评审功能走查用户会在哪里继续、重试或返回，避免只评审退出弹窗本身。

先分清“保存了”与“生效了”

这份活动表包含活动名称、报名说明和参与条件三个区域。用户修改后，内容可以先存为草稿；只有点击发布并得到成功结果，访客才会看到新版本。因此页头需要分别表达草稿状态和发布状态，例如“草稿已保存”与“尚未发布”。只放一个绿色勾号，无法说明究竟完成了哪一步。

如果产品决定采用手动保存，修改之后就持续显示“有未保存的修改”，并保留保存入口。如果采用自动保存，用户需要看见保存过程和失败出口，而不能被要求猜测系统多久保存一次。两种方式也可以共存，但应明确范围：正文自动保存，发布设置单独确认，不能让一个总状态掩盖局部未保存。

不要为了简化界面，把“保存草稿”和“发布活动”合成同一个无说明的按钮。它们的影响对象不同：前者保留编辑内容，后者改变外部可见结果。如果业务确实在保存后立即生效，就应改用符合实际后果的文案，而不是继续称作草稿。

一张表单至少需要五种可解释的状态

进入页面时，系统展示最近一次确认保存的内容。用户把活动名称从“秋季分享会”改为“设计分享会”，当前值与已保存版本不同，才进入未保存状态。若又改回原值，是否仍提示未保存，应依据实际数据比较，而不是因为用户曾按过键盘就永久记录为已修改。

状态最好位于稳定位置，例如标题旁或操作栏内，避免成功提示一闪而过，用户回头找不到保存结果。时间可以作为补充，但“刚刚保存”不能覆盖之后发生的修改；只要当前值又发生变化，状态就应随之更新。

自动保存中的请求可能先后返回。较早请求成功，只能确认它对应的版本，不能把之后新增的内容一起标成已保存。这类时间顺序可结合操作按钮反馈设计核对；在活动表中，用户看到的总状态必须与当前草稿对应。

站内返回与关闭浏览器，是两种不同的离开

点击站内“返回活动列表”时，应用通常可以展示自己的确认界面。这时可以准确告诉用户：“报名说明还有未保存的修改。”主要动作根据任务安排为“保存并返回”，次要动作是“继续编辑”，风险动作是“放弃修改并返回”。按钮直接说结果，比“确定／取消”更容易判断。

Shopify 的 Save Bar 文档将未保存提示与站内离开确认配合使用。这类模式适合参考，但活动表不需要照搬其具体组件：重点是保存入口持续可见，导航发生前有机会处理尚未保存的内容。

刷新页面、关闭标签页或离开整个网站则受到浏览器限制。MDN 对 beforeunload 的说明指出，浏览器离开警告的文字通常由浏览器决定，该事件在移动端等场景也不保证触发。因此，设计稿不能承诺关闭页面时总能弹出一张定制对话框，更不能把这张弹窗当成唯一的数据保护措施。

这一差异应落到交付说明中：站内返回使用产品自己的三选一决策；浏览器关闭采用平台允许的警告；突然退出时依靠已经完成的草稿保存或已实现的恢复机制。不要用“所有情况下均不丢内容”掩盖尚未支持的场景。

“保存并离开”必须等到保存有结果

用户选择“保存并返回”之后，可以把按钮改为“正在保存”，保留当前页面，成功后再返回列表。若保存失败，确认界面应留在可恢复状态，明确“草稿未保存，是否继续编辑”，而不是先跳走，再在列表角落出现一个用户来不及阅读的错误。

如果保存要求必填字段完整，草稿与发布规则也要分别确认。活动还没决定日期时，业务可能允许先存草稿、但不允许发布；不能在用户只是想保留工作时，强制他把整张表补齐。如果某些字段连草稿都无法保存，应说明原因，并把错误定位到相应字段。

等待期间如果仍允许编辑，就可能出现保存的旧版本与画面上的新内容不一致。对于“保存并离开”这个明确动作，可以暂时锁定本次保存范围，直到得到结果；若希望用户继续修改，则取消自动离开的意图，改为留在页面等待下一次确认。两种方案都比静默丢弃后续输入清楚。

“放弃修改”也要说明放弃范围。本例应恢复最近一次保存的草稿，不是删除整场活动，也不是回滚已经发布的版本。风险文案尽量指出真正会失去的东西，例如“放弃本次未保存的报名说明”，避免夸大为“所有内容将永久丢失”。

重新打开时，恢复的是哪份草稿

恢复入口应说明草稿所属的活动与时间，必要时显示部分内容预览。例如“发现这场活动在此设备上的未完成编辑，最后编辑于14:32”，然后让用户选择继续或使用已保存版本。不要只有一个“发现草稿”的弹窗，让用户不知道是否会覆盖同事刚改过的内容。

本地保留与服务端保存也不是同一件事。“已保存在此设备”不能写成“云端已保存”；换浏览器、清理站点数据或改用另一台电脑后的表现，需要与实际存储范围一致。涉及个人信息的活动表，还应沿用产品现有的访问与数据保留规则，不能为了恢复方便额外长期留存敏感字段。

如果另一位同事已更新活动，恢复旧草稿可能覆盖新内容。可以展示两个版本的时间与关键差异，让用户确认如何继续；没有合并能力时，提供复制文本或返回查看的路径，也比一个含糊的“覆盖”按钮更安全。设计不应把暂未实现的自动合并画成既有能力。

同一浏览器打开两个活动标签页时，每份草稿还必须归属正确对象。重新进入“设计分享会”，不应该弹出另一场活动的报名说明。用活动名称、记录标识和版本说明建立对应关系，界面才有条件准确解释恢复结果。

把离开决策放进一条可讨论的原型路径

在 Pixso 中建立同一份活动表，保留相同的字段与输入内容，分别画出未修改、未保存、保存中、保存失败和草稿已保存状态。将“返回活动列表”连接到确认界面，再把保存成功与失败的去向画清楚。活动发布入口放在独立位置，避免评审时混淆保存与发布。

可以让评审者先修改一段报名说明，再返回列表，随后模拟保存失败。他应当能够说出文字现在保留在哪里、下一步怎样重试，以及选择放弃究竟会恢复到哪个版本。通过评论把疑问留在具体按钮和状态文字旁，比只讨论“要不要加弹窗”更容易形成一致决定。

上线前再补几条容易被忽略的路径：修改后改回原值、保存中再次编辑、刚恢复草稿又离开、两个标签页同时打开。每一条都围绕同一个判断——当前页面是否还有未被确认保留的内容。离开保护做得好，用户不会被反复打断，也不会因一句过早出现的“已保存”失去刚完成的工作。