1. 项目背景与技术选型：离线读写痛点分析、主流方案对比、选型依据
移动端应用对网络条件的依赖程度日益降低，用户期望在弱网或无网环境下仍能流畅操作核心功能。传统在线直读 API 的模式在离线场景下暴露出严重缺陷：数据不可用、界面空白、操作失败。本章从工程实践角度拆解离线读写的深层痛点，对比主流方案，并给出选型决策框架。
离线读写场景：用户在地铁、电梯、地下室等网络不稳定区域发起 App 使用，或应用本身具备“先使用后同步”的产品逻辑（如笔记类、待办类、阅读类应用）。离线读写的本质是客户端本地持久化 + 异步同步网关。
1.1 离线读写的核心痛点
- 数据一致性风险：本地缓存与远端 API 数据在离线期间可能发生冲突，多设备多端同步时容易出现幻写、版本回退。
- 用户体验断层：若无本地数据支撑，用户进入页面即空白等待，甚至功能按钮失效，导致留存率下降。
- 开发维护成本飙升：需要同时维护在线 API 封装、本地存储引擎、冲突解决策略、同步队列、重试与幂等机制，团队人力投入成倍增加。
- 存储容量与性能：移动端存储空间有限，大量离线数据的索引、查询、清理策略若设计不当，会导致写放大或读取延迟。
1.2 主流方案对比
| 方案 | 实现方式 | 离线支持 | 冲突处理 | 跨平台 | 学习成本 |
|---|---|---|---|---|---|
| SQLite + 手动封装 | 原生 SQL / ORM | 强（需自建同步层） | 弱（需二次开发） | 全平台 | 中 |
| Realm | 对象数据库 | 内置同步 | 自动多版本 | iOS/Android/Flutter | 低 |
| Core Data | Apple 生态对象图 + 持久化 | 需搭配 CloudKit | 系统级（有限） | 仅 Apple | 中 |
| 文件存储 + 自定义格式 | JSON/Protobuf 本地文件 | 基础（无查询） | 无 | 全平台 | 低 |
| 本地 + 远程 GraphQL 缓存 | Apollo/Relay 缓存层 | 部分（依赖客户端缓存） | 弱（需自定义） | 全平台 | 高 |
痛点即方向：大部分离线读写失败的根本原因不在于本地存储能力，而在于“离线-在线”两套数据模型没有统一封装层。本课程选择 SQLite + 轻量 ORM + 自定义同步引擎 作为主线，兼顾灵活性、可控性和性能。
1.3 选型依据
决策过程围绕三个纬度：
- 业务数据模型复杂度：关系复杂时倾向 SQLite（支持 Join），对象简单且需要快速原型时考虑 Realm。
- 同步冲突容忍度：需要精确版本控制（如协同编辑）时需自建 CRDT 或增量同步，Realm 的内置同步不够灵活。
- 团队技术栈：已有 SQL 经验团队更适合 SQLite，无数据库背景可优先 Realm 降低入门成本。
最终选型决策流程如下（图中橙底节点为本课程所选方案）：
本课程采用 SQLite + 轻量 ORM + 同步队列封装 作为主线方案，理由如下：
- 完全控制权：不依赖第三方同步黑盒，可精细控制冲突解决策略（最后写入/版本向量/CRDT）。
- 通用性：SQLite 在所有主流平台（iOS/Android/WebAssembly）均有原生绑定，课程示例可跨平台复用。
- 性能基线：经过索引优化和 WAL 模式配置，离线写入性能优于多数对象数据库。
- 团队技能复用：SQL 技能迁移成本低，封装层只需聚焦同步逻辑，而非学习全新数据库范式。
选型风险提示：SQLite 方案需要额外投入同步引擎的测试与稳定性建设，不适合 2 周内快速上线的小型 Demo。如果团队以快速验证业务为主，建议优先考虑 Realm 内置同步。