数据存哪儿、用什么形态存，是应用架构绕不开的第一道题。鸿蒙 ArkData 给了三套主流存储——用户首选项、键值型数据库、关系型数据库，外加分布式对象、跨应用共享、向量数据库这些进阶能力，选项一多反而容易选错。下面把 ArkData 的能力地图画清楚，再给一套选型决策方法。

一、ArkData 在解决什么问题

ArkData（方舟数据管理）的定位很明确：为开发者提供数据存储、数据管理和数据同步三大能力。官方文档举的例子很形象——联系人应用的数据要存进数据库，要保证安全可靠、能被其他应用共享访问，还要能跟手表同步联系人信息。这三件事分别对应存储、管理、同步。

ArkData 的能力可以分成四块：

1. 标准化数据定义：跨应用、跨设备的统一数据类型标准
2. 数据存储：用户首选项、键值型数据库、关系型数据库（含向量数据库）
3. 数据管理：权限管理、数据备份恢复、跨应用数据共享框架
4. 数据同步：跨设备数据同步、端云数据同步、分布式对象

一个关键事实：应用创建的数据库保存在应用沙盒中，卸载应用时数据库自动删除。 数据生命周期和应用绑定，跨应用共享得走专门的 DataShare 机制。

二、三种存储形态的本质差异

选型的核心是理解三种存储形态各自适合什么。官方描述偏抽象，拿实际场景对照一下。

2.1 用户首选项（Preferences）

本质：一个会全量加载到内存的键值对文件。

运作机制：每个持久化文件唯一对应一个 Preferences 实例，系统通过静态容器把这个实例存在内存里。也就是说，你一打开它，所有数据就都进内存了。

适合：轻量级配置数据——字体大小、夜间模式开关、用户偏好设置。这类数据量小、读频繁、写不频繁，全量进内存反而最快。

不适合：大数据量。官方建议存储数据不超过 50MB，超过这个量，创建实例和持久化都会变成耗时操作，在主线程上跑可能引发 appfreeze。

2.2 键值型数据库（KV-Store）

本质：以"键值对"组织数据的非关系型数据库。

适合：数据关系简单、业务关系少的场景。比如商品名称对应价格、员工工号对应今日是否出勤。这类数据没有复杂的多表关联，用 KV 反而清爽。

分布式优势：官方特别强调，KV-Store 在分布式场景里"降低了解决数据库版本兼容问题的复杂度和数据同步过程中冲突解决的复杂度"。简单说，跨设备同步时，KV 比关系型更容易做到跨版本兼容。如果你的数据要跨设备同步，且关系不复杂，KV 是首选。

2.3 关系型数据库（RelationalStore）

本质：基于 SQLite 的关系型数据库，行和列存储。

适合：数据之间有较强对应关系的场景。一个班级的学生信息（姓名、学号、各科成绩），公司的雇员信息（姓名、工号、职位），这些数据天然是表格化的、有外键关联的。

额外能力：支持事务、索引、视图、触发器、外键、参数化查询、预编译 SQL，还能跑自定义 SQL。从 API 起还内置了向量数据库能力，支持向量相似度计算，适合推荐、相似图像检索、NLP 场景。

三、一张选型决策表

把三种存储的核心维度拉出来对比，选型时一目了然：

维度	用户首选项	键值型数据库	关系型数据库
数据形态	键值对（全量入内存）	键值对	行列表格
适合数据量	轻量级（<50MB）	中等	中等到较大
数据关系	无	简单	复杂关联
查询能力	按 key 取值	按 key 取值	SQL 全套 + 谓词
跨设备同步	不支持	支持，兼容性好	支持，需配置
加密	不支持（需自行加密）	支持	支持
全文检索	不支持	不支持	支持（FTS）
向量检索	不支持	不支持	支持
典型场景	配置、偏好	简单业务数据	复杂业务、需要 SQL

四、实战选型决策树

光看表还不够，给一个实战中好用的决策流程，按顺序问自己几个问题：

问题 1：数据量多大？

• 很小（KB 级，配置类）→ 用户首选项
• 中等到大 → 继续往下

问题 2：数据之间有关系吗？

• 没什么关系，就是一堆独立的键值 → 键值型数据库
• 有表关联、需要多表查询、需要复杂条件过滤 → 关系型数据库

问题 3：要跨设备同步吗？

• 要同步，且数据关系简单 → 键值型数据库（同步兼容性更好）
• 要同步，且数据关系复杂 → 关系型数据库（需配置分布式表）
• 不需要同步 → 看问题 2

问题 4：有特殊需求吗？

• 需要全文检索 → 关系型数据库（FTS）
• 需要向量相似度（推荐、检索）→ 关系型数据库（向量能力）
• 需要跨应用共享 → 任意存储 + DataShare 框架

五、几个实战场景的选型结论

用具体业务场景走一遍决策树，印象会更深。

场景 A：用户设置（主题、字号、夜间模式）
→ 用户首选项。数据量小、读多写少、无需同步。

场景 B：购物车的商品列表
→ 键值型数据库。商品 ID 映射到数量/规格，关系简单，可能要跨设备同步（手机加购物车，平板上也能看到）。

场景 C：订单系统（订单、订单明细、商品、用户多表关联）
→ 关系型数据库。订单和明细是一对多，商品和订单是多对多，这种关系用 SQL 处理最自然。

场景 D：聊天记录的全文搜索
→ 关系型数据库 + FTS。聊天记录本身是关系型，搜索用 FTS 虚拟表 + 中文分词器。

场景 E：图片的"以图搜图"
→ 关系型数据库的向量能力。把图片特征向量存进去，用相似度计算检索。

场景 F：联系人同步到手表
→ 关系型或键值型 + 分布式表。联系人数据有结构但关系不复杂，两种都可行；如果还要跨设备改冲突处理，关系型单版本表模式更合适。

六、ArkData 的运作机制：六个部件

理解了选型，再快速过一下 ArkData 内部的六个部件，知道每件事是谁干的：

• Preferences：轻量配置持久化，支持订阅变更，不支持分布式
• KV-Store：键值数据库，读写/加密/备份/订阅，分布式同步走 DatamgrService
• RelationalStore：关系型数据库，增删改查/加密/备份/订阅，外加向量能力
• DataObject：分布式数据对象，内存对象跨设备共享
• DataShare：跨应用数据交互的 provider-consumer 模式，支持静默访问
• UDMF：统一数据管理框架，定义跨应用跨设备的数据交互标准

还有一个幕后角色 DatamgrService（数据管理服务），它负责所有跨设备同步、端云同步、静默访问、对象暂存等"需要跨边界"的操作。你本地 CRUD 不会经过它，一旦涉及同步或共享，请求就会被发到 DatamgrService 由它完成。

七、模拟器的限制要知道

在模拟器上开发 ArkData，有几个能力差异要心里有数：

• KV-Store 只支持本地增删改查，分布式等其余能力不支持
• RelationalStore 同样只支持本地增删改查
• DataObject 的端端能力依赖接续框架，模拟器上只支持手机

所以分布式同步相关的开发，模拟器只能写代码，验证得用真机组网。

八、选型一句话

ArkData 的选型核心：按数据量和数据关系选形态，按同步和特殊需求选进阶能力。

• 配置类 → Preferences
• 简单键值 → KV-Store
• 复杂关系 → RelationalStore
• 跨设备 → 在 KV 或 RDB 上开分布式表
• 跨应用 → 任意存储 + DataShare
• 全文检索/向量 → RelationalStore 的进阶能力

后面会沿着"Preferences → KV-Store → RelationalStore → 分布式 → 进阶"这条线，每篇配完整实践案例，把选型之后的"怎么用"讲透。