鸿蒙应用数据持久化选型：Preferences、关系型数据库与文件的边界

一、持久化不是“存下来”这么简单

多数应用都会遇到同一类问题：配置要记住、列表要缓存、用户数据要落盘。很多开发者的做法是“全都用一种方式存”，要么全塞进键值对，要么全写文件。结果要么是读取越来越慢，要么是数据一多就找不到、改不动。

持久化的关键不是“能不能存”，而是按数据的形态和生命周期选对方式。鸿蒙应用常用的三类手段各有明确边界：键值存储适合小而离散的配置，关系型数据库适合结构化且有查询需求的业务数据，文件适合大体量、顺序读写的内容。

二、键值存储：小配置的默认选择

系统提供的轻量键值存储，适合存放：

• 主题、语言、开关类偏好设置；
• 上次浏览位置、引导页是否展示；
• 小型状态标记，如“首次启动”“协议已同意”。

它的优点是同步接口简单、读取快；代价是不适合大 value 和复杂结构。实践中建议：

1. key 命名带模块前缀，避免不同模块互相覆盖；
2. 单个 value 控制在较小体积，列表和对象不要整体序列化后塞进去；
3. 频繁变更的计数类数据不要放在这里，写放大得不偿失。

一个判断标准：如果某项数据需要“按条件查一部分”，它就不该放在键值存储里。

三、关系型数据库：有查询就有表

一旦数据满足以下任一特征，就应该建表：

• 需要按字段过滤、排序、分页；
• 数据之间有关联（用户与订单、分类与条目）；
• 需要部分更新而不是整体覆盖。

比如待办清单、笔记、聊天记录，都属于这一类。实践中容易踩的坑：

1. 主键与索引：查询字段建索引，主键不要用业务含义不稳定的字段；
2. 时间字段：统一存 UTC 毫秒值，展示层再格式化，避免时区错乱；
3. 升级策略：建表语句集中管理并带版本号，升级时只做增量迁移，不要在启动时反复“删了重建”；
4. 事务：多条写入要么都成功要么都回滚，尤其是“删除旧数据 + 写入新数据”这类成对操作。

另一个常见误区是把数据库当成缓存用，频繁整表读写。数据库的价值在于查询，如果每次都是全量读取，说明数据形态可能更适合文件或内存结构。

四、文件：大内容与顺序数据的归宿

文件适合：

• 图片、音频、导出的文档；
• 日志与调试记录；
• 一次写入、整体读取的内容，如缓存的页面快照。

使用文件时的三条纪律：

1. 路径规划要区分“应用私有目录”与“可分享目录”，私有数据不要落到公共区域；
2. 写入采用“临时文件 + 原子改名”的方式，避免写一半被中断导致内容损坏；
3. 定期清理不再使用的文件，尤其是缓存目录，否则占用会只增不减。

五、三类方式的组合使用

真实应用往往是三者配合：

• 偏好设置走键值存储；
• 业务数据进数据库；
• 媒体与大内容落文件，数据库里只存路径与元信息。

这样每一层都保持简单：数据库不存二进制大对象，文件不承担查询职责，键值存储不存放结构化列表。

六、敏感数据的额外处理

无论用哪种方式，涉及账号凭据、个人信息的数据要额外注意：

1. 不要明文落盘，至少做加密后再存储；
2. 提供退出登录时的本地数据清理逻辑；
3. 日志里不要输出凭据与个人字段，调试信息上线前要关闭。

持久化方案的安全性，往往在代码评审时最容易被忽略，却在线上出事时代价最大。

七、小结

持久化选型的原则可以概括成一句话：按查询需求选数据库，按体积和形态选文件，剩下的配置交给键值存储。把边界划清楚，再配合统一的版本迁移与清理策略，数据的可靠性和应用的性能都可以长期保持在一个健康的水平。