1. 数据存储概述：鸿蒙本地存储方案对比
做鸿蒙开发这几年，我接触最多的就是数据存储这块。说实话，刚入坑的时候我也挺懵的——这么多存储方案，到底该用哪个？
今天咱们就把鸿蒙的四种本地存储方案掰开揉碎了讲清楚。分别是：Preferences、KVStore、SQLite 和 分布式数据对象。
核心观点：没有最好的方案，只有最合适的方案。选错了存储方案，后面改起来真的很痛苦——我踩过这个坑。
1.1 四种方案速览
先看一张图，帮你快速建立整体认知：
1.2 Preferences —— 轻量级键值对
Preferences 说白了就是个轻量级的存储工具。它存的是键值对，就像你手机里的设置开关——记住你上次选了深色模式还是浅色模式。
适用场景：
- 用户偏好设置（主题、字体大小）
- 应用配置项（是否首次启动）
- 缓存一些简单的状态值
我的经验：Preferences 适合存 < 100 条数据。我之前有个项目硬往里塞了 500 条配置，结果读取速度明显变慢。后来果断换成了 KVStore。
优缺点：
| 优点 | 缺点 |
|---|---|
| API 简单，几行代码搞定 | 不支持复杂查询 |
| 读写速度快（内存缓存） | 数据量大了性能下降 |
| 自动管理生命周期 | 不支持分布式同步 |
1.3 KVStore —— 分布式键值数据库
KVStore 是 Preferences 的升级版。它也是键值对，但多了分布式能力。什么意思呢？就是你的手机和平板可以共享同一份数据。
适用场景：
- 需要在多设备间同步的简单数据
- 用户登录状态、设备绑定信息
- 轻量级的配置同步
注意：KVStore 虽然支持分布式，但它的同步是有延迟的。我曾经做过一个实时协作的小工具，发现数据同步要等 1-2 秒，用户体验很差。后来改用了分布式数据对象才解决。
1.4 SQLite —— 关系型数据库
SQLite 大家应该不陌生。它是嵌入式关系型数据库，支持 SQL 查询。如果你要存的数据有复杂的关系，或者需要做各种筛选排序，那就选它。
适用场景：
- 聊天记录、通讯录
- 购物车、订单数据
- 任何需要 CRUD 操作的场景
避坑指南：我曾经在一个项目里用 SQLite 存了 10 万条日志，查询时没加索引，结果页面卡了 3 秒。记住：数据量大了一定要建索引！
1.5 分布式数据对象 —— 内存级实时同步
这个方案比较特殊。它不存到磁盘，数据在内存里。多个设备之间可以实时共享同一个对象。你改一下，那边立刻就能看到。
适用场景：
- 实时协作编辑（比如一起画图）
- 多屏互动（手机控制电视）
- 游戏中的实时状态同步
我的建议：分布式数据对象虽然好用，但数据是存在内存里的。应用被杀掉数据就没了。所以重要数据一定要配合持久化方案一起用。
1.6 如何选择？一张表搞定
| 需求 | 推荐方案 | 理由 |
|---|---|---|
| 存几个用户设置 | Preferences | 简单、轻量、够用 |
| 多设备同步配置 | KVStore | 自带分布式能力 |
| 存大量结构化数据 | SQLite | 查询灵活、性能稳定 |
| 实时同步状态 | 分布式数据对象 | 毫秒级同步 |
| 又大又要同步 | SQLite + 分布式数据对象 | 组合使用，各取所长 |
嗯，到这里你应该对四种方案有了整体认识。后面几章我们会逐个深入，手把手带你写代码。记住我一句话：选对方案，后面省一半的功夫。