1、离线优先架构概述

大家好，我是做移动端架构的老工程师。今天咱们聊聊离线优先——这个我在好几个项目里踩过坑、也收获巨大的模式。

什么是离线优先模式？

说白了，离线优先不是“在没网的时候凑合用”，而是从设计第一天就把离线当作一等公民。你的App必须能在无网络状态下独立运行，网络恢复后自动同步。而不是等到用户抱怨“没网就看不了”才去补救。

我最早接触这个思路是在2018年做电商App的时候。当时团队习惯“在线优先”——先调接口，接口失败再提示无网络。后来用户反馈“在地铁里根本刷不出商品列表”，我们才意识到方向反了。

离线优先的核心就一句话：本地是真相，网络是增量。

核心理念

• 本地优先写入：用户操作先写入本地数据库（Room / SQLDelight），再异步同步到服务端。
• 乐观更新：假设操作会成功，直接更新UI，不等待网络响应。
• 冲突解决：当多个客户端修改同一条数据时，定义合并策略（例如基于时间戳、LWW或自定义规则）。
• 网络感知：监控连接状态，自动切换数据源（本地/远程），并提供队列与重试机制。
• 数据一致性：最终一致，而不是强一致。用户看到的数据允许短暂滞后，但不会丢失。

适用场景

并非所有App都需要离线优先。我总结几个典型场景：

1. 协作办公工具：比如笔记、任务管理、白板——用户在飞机上、地下室也需要编辑。
2. 电商/内容消费：商品浏览、购物车——网络不稳定时不能卡死。
3. 生产力和医疗：字段填写、签到打卡——数据必须不丢失。
4. IoT / 现场服务：维修工单、设备巡检——偏远地区网络差。
5. 金融交易：部分离线支付场景——本地记录后后台对账。

你想想看，如果你的用户经常在电梯、隧道或境外使用App，离线优先几乎是刚需。反之，纯流媒体或实时游戏则不太适合——它们依赖低延迟网络交互。

传统在线优先 vs 离线优先

维度	在线优先 (Online‑First)	离线优先 (Offline‑First)
数据流向	请求 → 服务端 → 响应 → 更新UI	写入本地 → 乐观UI → 异步同步到远端
网络依赖	强依赖，无网络直接失败	弱依赖，本地独立运行
用户体验	加载转圈 + 错误提示	即时响应 + 后台静默同步
架构复杂度	低，CRUD + REST即可	中高，需要本地数据库、同步引擎、冲突处理
数据一致性	强一致（依赖服务端）	最终一致（本地+远程合并）
典型失败案例	用户在隧道内无法发送消息	修改冲突导致数据覆盖

我曾经接手过一个“在线优先”的旧项目，上线后用户投诉“点击保存后什么都没发生”——其实是网络超时，App直接吞掉了数据。改造成离线优先后，所有操作先落盘，用户从此不再丢数据。但代价是同步逻辑复杂了大概3倍。

什么时候该选离线优先？

别被“复杂”吓到。我建议你从这两个问题判断：

• 用户是否会频繁在网络差的环境下使用？
• 数据丢失是否会造成严重后果？

如果答案都是“是”，那就别犹豫。否则，在线优先更轻量。注意，不要滥用——比如一个新闻阅读App，只在缓存文章时做离线缓存就够了，不必让整个架构都离线优先。

挑战与应对

离线优先不是银弹。几个常见坑：

• 冲突复杂度：两个人同时编辑同一行文字，谁覆盖谁？我习惯用“最后写入者胜出（LWW）”加修改时间戳，但这不一定适合所有业务。比如医疗记录，需要CRDT（无冲突数据类型）才能保证合并后语义正确。
• 存储膨胀：本地数据库会不断积累数据。需要设计清理策略（例如只保留30天内的记录）。
• 同步顺序：离线期间产生的操作如果按先进先出推送，可能违反业务依赖。比如先删除后创建vs先创建后删除。我个人建议用同步队列+操作依赖来排序。

离线优先架构知识体系

下面这张图概括了本章的核心逻辑：从理念到落地需要关注的模块。

图中展示了四大核心模块：本地数据层、同步引擎、冲突解决策略、UI层和一致性保证。每个模块在后面的章节都会详细展开。