断网后还能用的 App，提前做对了什么？

列车开进隧道，网络断了。你打开一篇刚才读过的文章，还能继续往下看；切到另一个 App 查看行程，页面却只剩加载动画。

同样一部手机，同样没有网络，体验差了不少。

能继续工作的那个 App，往往是在断网之前就做了准备：把需要的内容留在本地，把用户刚才的修改保存下来，也知道哪些事情必须等联网后才能确认。

本地有什么，断网后才能用什么

离线阅读最容易理解。文章已经完整保存在手机里，继续看不需要每次都去服务器取。

但“打开过”不一定等于“全部下载过”。正文可能已经有了，下面几张图片还没加载；地图显示过当前位置，也未必保存了接下来要走的区域。

设计离线能力时，需要把可用范围说明白。明确下载了一份离线内容，与系统碰巧留下了一些缓存，不是同样可靠的承诺。缓存可能被清理，首次安装的设备也不会凭空拥有内容。

因此测试至少应分两种情况：提前加载过，再断网；从未加载过，直接离线打开。前者看能保留多少体验，后者看能否准确解释缺少什么。

有旧数据，不代表它现在仍然正确

小说章节放几天通常没什么变化，航班登机口、商品库存和订单状态就不一样。

离线时展示旧行程，可以帮助用户找到之前保存的航班信息，但应该注明更新时间。不能把旧登机口包装成刚刚确认的实时结果。

缓存本身也有使用规则。HTTP 缓存规范区分了新鲜与过期响应，并规定何时允许使用过期内容；存在禁止复用或必须重新验证的要求时，不能因为断网就一概忽略。RFC 9111：过期缓存的使用

应用自己保存的业务数据，还需要结合产品语义制定规则。哪些可以只读展示，哪些必须重新确认后才能操作，不能仅靠一个统一的缓存时长解决。

对用户来说，一句“显示的是上次同步内容”，往往比完全白屏有用，也比悄悄展示过期数据诚实。

“已保存”到底保存到哪里了？

假设你在地铁里写了一段笔记，页面提示已保存。回到电脑前，却找不到它。

手机可能已经把内容写入本地，只是还没同步到服务器。数据未必丢了，但用户对“已保存”的理解与产品不一致。

比较清楚的表达是把本地保存和同步状态分开。用户编辑后先可靠地保存到设备，离线期间标记待同步，服务端确认后再显示同步完成。

这还要求“本地保存”真正能承受退出和进程结束。如果文字只存在当前页面的内存里，切个页面就消失，就不该提前承诺已经保存。

草稿尤其如此。网络请求失败可以重发，用户刚写的几百字未必愿意再写一遍。先把它留住，是很值得优先做的事情。

断网时能编辑，不代表所有操作都能先做后补

笔记修改可以先在本地记录，消息可以进入待发送队列。网络恢复后，再尝试同步。

但普通在线购买不能因为手机记下了一次点击，就显示订单已经成立。价格、库存和服务端处理结果还需要确认。离线时可以保存购买意图，等联网后继续流程，但要让用户知道它尚未完成。

一些专门设计的业务确实有离线授权机制，那需要额外协议和风险控制，不能从“笔记可以离线写”推导出所有业务都适合这么做。

操作	离线期间可考虑的行为
阅读已下载文章	展示本地内容，缺失资源单独提示
编辑笔记	保存草稿，标记尚未同步
发送消息	明确显示待发送，允许用户取消
普通在线下单	保存选择，联网后重新确认并提交

这些行为解决的是不同需求，页面上的“成功”也要有不同的依据。

等待同步的队列，要记得用户后来做过什么

用户断网时发了一条消息，又发现写错了，选择取消。恢复联网后，如果系统仍把原消息发出去，离线能力就帮了倒忙。

类似地，用户连续修改同一条笔记，系统需要知道哪些修改仍然有效。服务端接收过一次、确认却没有返回时，再次同步还要避免重复创建内容。

待同步队列因此不能只是“把失败请求都存起来，联网后挨个重放”。它要保留业务身份和当前意图，处理取消、依赖顺序与重复提交。

失败也需要分类。网络暂时不通可以稍后重试；权限被撤销、任务过期或内容不再允许提交，继续重试通常没有用。用户应该能看到失败原因，保留可挽回的本地内容。

两台设备都改了笔记，听谁的？

再把场景加一点变化。

手机离线时，你改了会议时间。与此同时，电脑在线修改了同一份笔记的地点。手机恢复联网后，如果直接拿整个旧文档覆盖服务器，电脑上的新地点就可能丢失。

“最后上传的版本获胜”实现起来直观，却不一定符合用户的真实意图。上传时间晚，可能只是那台设备刚刚恢复网络。

有些字段可以按业务规则合并，有些冲突适合保留两个版本，让用户选择。文本协同还可以使用专门的同步机制，但不用一开始就把所有 App 都做成协作文档系统。

先识别哪些数据可能被多端修改，再为它们定规则。无法可靠合并时，保留冲突副本通常比静默丢掉一边内容更容易补救。

离线测试要包含“关掉再打开”

把网络关掉，页面还能显示，只验证了很小一部分。

可以用一份测试笔记跑完这个过程：正常联网打开，断网后修改，退出页面，再结束进程并重新打开，最后恢复联网。

检查本地修改是否还在、待同步状态是否准确，以及服务端最终是否只有一份正确内容。接着加入取消操作、账号切换和多设备修改，观察系统是否按约定处理。

账号切换尤其需要小心。属于前一个账号的待同步内容，不能随着新账号登录就被提交到错误位置。本地敏感内容的保留或清除，也要有明确策略。

这些实验最好使用测试账号和可丢弃的数据。验收时分别记录“本地持久化成功”和“服务端同步成功”，不要只留一个含糊的保存结果。

从一份不会丢的草稿开始

不是每个 App 都需要完整离线模式。对于主要依赖实时信息的产品，一份可靠草稿、几条可查看的历史记录，以及准确的待同步提示，就可能解决很多实际问题。

先挑用户最不愿意重做的那件事，把它保存好。下次列车进隧道，用户即使暂时发不出去，也能安心继续写，知道这些字不会随着加载失败一起消失。