鸿蒙应用本地数据存储实战：Preferences 与关系型数据库选型指南

鸿蒙应用几乎离不开本地存储：用户的设置、登录状态、离线缓存、业务数据，都要落到设备上。选错存储方式，后面不是性能问题就是维护成本。本文讲清楚鸿蒙应用里两种最常用的本地存储——Preferences 与关系型数据库——分别适合什么场景，以及落地时要注意的细节。

一、先想清楚：你要存的是什么

动手选型之前，先把数据分成三类：

1. 配置类数据：主题选择、是否首次启动、用户偏好开关。特点是量小、结构简单、读写频繁。
2. 业务结构化数据：待办事项、订单记录、聊天消息。特点是量大、有查询和筛选需求、数据之间有关联。
3. 文件类数据：图片、音频、下载的文档。特点是体积大、不适合放进数据库字段。

配置类数据用 Preferences，业务结构化数据用关系型数据库，文件类数据走文件系统并只在数据库里存路径。这个分工定下来，后面就不会出现“把图片塞进数据库”或者“用键值对存几千条记录”这类问题。

二、Preferences：轻量配置的首选

Preferences 是鸿蒙提供的轻量级键值存储，适合保存应用的配置信息。它的优点是使用简单、读写快，不需要写 SQL，几行代码就能完成一次存取。

典型用法是保存用户的设置项：

// 保存一个用户偏好
preferences.setSync('dark_mode', true);
preferences.flush();

// 读取时给一个默认值，避免首次启动取不到值
const darkMode = preferences.getSync('dark_mode', false);

用 Preferences 时要注意三点：

• 不要存大量数据：它不是为海量数据设计的，几千条键值对会让加载变慢。
• 不要存敏感信息：Token、密码这类数据不要明文放进 Preferences，需要加密或走更安全的存储。
• 键名要规范：用统一的前缀区分模块，比如 settings_、user_，避免键名冲突。

三、关系型数据库：结构化数据的正解

当数据量上来、需要按条件查询和排序时，就该用关系型数据库。鸿蒙的关系型数据库支持标准的 SQL 能力，建表、增删改查、事务都齐全。

以一个待办清单为例，建表和写入的思路是这样的：

-- 一张待办表，字段即业务属性
CREATE TABLE IF NOT EXISTS todo (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  title TEXT NOT NULL,
  done INTEGER DEFAULT 0,
  created_at INTEGER NOT NULL
);

// 插入一条待办
valuesBucket.put('title', '提交周报');
valuesBucket.put('created_at', Date.now());
relationalStore.insert('todo', valuesBucket);

// 按创建时间倒序查出未完成的待办
const result = relationalStore.querySql(
  'SELECT * FROM todo WHERE done = 0 ORDER BY created_at DESC'
);

关系型数据库的优势在于查询能力：按状态筛选、按时间排序、模糊搜索标题，这些需求用 SQL 一句话就能表达，不用把全量数据读出来再在内存里过滤。

四、选型对照：一个简单的判断流程

遇到一个存储需求时，可以按这个顺序判断：

1. 是配置项、开关类、少量键值吗？是 → Preferences。
2. 需要多条件查询、排序、分页吗？是 → 关系型数据库。
3. 数据量会持续增长到几千条以上吗？是 → 关系型数据库。
4. 是图片、音视频等大文件吗？是 → 文件系统 + 数据库存路径。

这个流程覆盖了绝大多数日常场景。判断不下来的时候，优先选关系型数据库：它扩展性更好，后面加查询条件不用重构存储层。

五、落地时的几个实用建议

• 数据库操作不要放在主线程：批量写入和复杂查询放后台执行，避免界面卡顿。
• 写操作尽量用事务：一次导入多条数据时包在一个事务里，失败整体回滚，速度也比逐条提交快得多。
• 给查询字段加索引：经常按状态、时间筛选的字段建好索引，数据量上来之后差距非常明显。
• 做好版本升级：表结构变化时用版本号管理升级逻辑，旧版本用户升级应用后数据不能丢。
• 定期清理过期缓存：离线缓存要有过期策略，避免数据库无限膨胀。

结语

Preferences 与关系型数据库不是竞争关系，而是分工关系：前者管配置，后者管业务数据。先把数据分类，再按分类选存储，鸿蒙应用的本地存储就能做到既简单又可靠。把这个分工想清楚，比纠结某个 API 的细节重要得多。