1. 离线优先架构总览

1.1 定义与核心思想

离线优先（Offline-First）是一种将离线能力视为一等公民的架构范式。其核心主张是：应用在没有网络连接时仍能提供完整的核心功能，网络仅作为数据同步与协作的增强通道，而非功能的前提条件。

与传统的"在线优先"（Online-First）不同，离线优先在设计之初就将本地数据处理、本地持久化、冲突解决和延迟同步纳入架构顶层决策，而非作为事后补丁。这要求架构师从数据流、信任模型、状态管理和同步协议四个维度重新定义系统边界。

1.2 核心挑战

离线优先架构面临四个主要挑战，这些挑战直接影响架构分层与组件选型：

• 数据冲突：多端离线编辑同一数据时，如何自动检测冲突并以可预测策略合并，避免数据丢失；
• 同步可靠性：网络波动、应用被杀死、存储写满等异常场景下，同步队列如何保证不丢数据、不重复提交；
• 本地存储边界：本地空间有限，如何设计数据淘汰策略、分页缓存和增量同步，避免存储膨胀；
• 一致性与时效性：离线操作在同步后可能与云端状态矛盾，如何平衡"最终一致"与用户期望的"即时反馈"。

1.3 适用场景

以下场景中离线优先架构的投入产出比最高：

• 移动端企业应用（巡检、外勤、库存盘点）—— 网络不稳定，操作需要即时响应；
• 全球协作平台（文档编辑、白板、项目管理）—— 跨时区、跨网络，多人离线编辑后合并；
• IoT边缘设备（工业传感器、车载终端）—— 设备在断网区域运行，需要本地决策与延迟上报；
• 远程医疗/教育 —— 网络质量差，但核心流程不能中断；
• 金融交易终端（离线支付、POS机）—— 必须支持先操作后联机清算。

1.4 与传统架构对比

下表从架构层面直接对比离线优先与传统的在线优先模式：

1.5 架构边界与系统分层

离线优先架构的边界以"本地自治"为第一原则，系统从上到下分为五层，每层的职责与数据流方向明确。下图展示了核心组件及其协作关系：

系统分层从下到上依次为：

• 本地持久化层：SQLite / IndexedDB / LevelDB，负责离线数据存储与本地查询；
• 数据访问层：提供本地CRUD API，封装存储细节，支持数据变更事件发布；
• 同步引擎层：核心组件，管理变更日志、冲突检测、同步队列与重试策略；
• 网络适配层：检测连接状态，维护请求队列，处理网络切换事件；
• 云服务层：接收同步请求，执行云端合并，返回确认与冲突结果。

1.6 模块职责

1.7 数据流与信任链路

离线优先架构中的数据流具有明显的非对称特征：本地操作即时写入本地存储，随后通过异步同步通道到达云端；云端处理结果沿反向路径回流。信任链路从"本地存储→同步引擎→云端"逐级传递，每一跳都需要校验数据完整性、身份与版本。

一个典型的写操作数据流包含以下阶段：

1. 用户发起写操作 → 本地API立即写入本地数据库，返回成功给用户；
2. 变更追踪器生成一条变更记录（含实体ID、操作类型、版本戳、数据摘要）；
3. 同步引擎读取变更记录，加入同步队列；
4. 网络可用时，引擎将批次变更发送到云服务网关（加密 + 签名）；
5. 云端校验身份、检测版本冲突，执行合并或标记冲突；
6. 云端返回确认（含最新版本戳）→ 同步引擎更新本地版本向量。

信任链路的三个关键点：

• 本地信任：所有本地写入被视为"待确认"状态，本地用户可立即看到结果；
• 传输信任：同步请求必须携带签名和版本戳，防止重放与篡改；
• 云端信任：云端以"接收方权威"决定最终版本，并通过同步响应将裁决结果下发。

1.8 选型权衡

在离线优先架构的技术选型中，以下权衡需要根据业务场景做出决策：

以下是一个典型的同步引擎配置片段，展示了选型决策的落地形态：

sync:
  strategy: "last-write-wins"
  conflict_resolution: "timestamp"
  retry:
    max_attempts: 5
    backoff: "exponential"
    initial_interval_ms: 1000
    max_interval_ms: 60000
  batch:
    size: 50
    compression: "gzip"
  encryption:
    algorithm: "AES-256-GCM"
    key_provider: "cloud_kms"
    rotation_days: 30
  network:
    probe_interval_ms: 5000
    offline_mode: "queue_and_notify"

1.9 风险点

1.10 落地步骤

从零到一落地离线优先架构，建议按以下阶段渐进推进：

1. 识别离线场景与数据域：梳理业务中哪些功能必须离线可用，哪些数据需要多端同步，标注冲突敏感度；
2. 定义数据版本模型：确定实体版本向量（Vector Clock）或混合逻辑时钟（HLC）方案；
3. 选择本地存储引擎：根据数据结构和查询模式选定 SQLite / IndexedDB / LevelDB；
4. 搭建同步引擎原型：实现变更追踪、同步队列、冲突检测与重试机制；
5. 设计同步协议：定义请求/响应格式、认证方式、加密与压缩策略；
6. 开发网络适配层：实现连接检测、离线/在线事件分发、请求队列管理；
7. 集成云端同步端点：部署云服务网关，对接后端数据库，完成端到端同步流；
8. 注入冲突策略与监控：根据业务选择LWW或CRDT，配置同步延迟告警与冲突率看板；
9. 全链路测试：覆盖离线写入、断线重连、冲突合并、存储满回退等异常场景；
10. 灰度发布与验收：从1%用户逐步放量，观察同步延迟、冲突率和本地存储水位。

1.11 验收标准

第1章的总览阶段，架构是否达到可进入下一章（详细设计）的基线，需满足以下验收项：

完成以上验收后，即可进入第2章对同步引擎与冲突策略的详细设计。