摘要

本文讲 HarmonyOS 轻量本地存储的工程化写法。以“转盘决定吧”为例，应用需要保存设置、历史记录、自定义转盘和当前选中转盘。技术重点是：页面不直接操作 Preferences，而是通过 service 层统一读写。

1. 为什么用 Preferences

本项目数据规模小、结构简单：

app_settings_v1      设置 history_records_v1   历史记录 wheels_v1            转盘列表 active_wheel_id      当前转盘

这些数据适合 Preferences，不需要上来引入 RDB。

2. 错误写法：页面直接持久化

不推荐：

Page -> getPreferences -> put -> flush

问题是：

• 页面重复代码多
• JSON 解析散落各处
• 默认值不好统一
• 数据结构升级困难
• 异常处理不一致

3. 推荐写法：服务层封装

推荐链路：

Page/View   -> HistoryService / SettingsService / WheelService   -> PreferencesStore   -> HarmonyOS Preferences

页面只调用业务语义：

await HistoryService.addRecord(record); await SettingsService.update(settings); await WheelService.saveWheel(wheel);

底层怎么序列化、flush、兜底，页面不关心。

4. PreferencesStore 的职责

底层 Store 负责：

获取 preferences 实例 封装 getString / putString JSON.stringify JSON.parse 默认值兜底 异常捕获 flush

业务服务负责：

历史记录最多保留多少条 默认转盘如何生成 设置字段如何合并 当前选中项是否合法

不要把这两层混在一起。

5. 历史记录截断

历史记录要限制数量：

const MAX_HISTORY = 500; records.unshift(newRecord); records = records.slice(0, MAX_HISTORY);

否则 Preferences 中 JSON 会越来越大，影响启动读取和页面刷新。

6. 本地存储和隐私说明

技术实现会影响隐私材料。既然保存了本地记录，就应该说明：

应用会在本地保存用户设置、历史记录和自定义选项，用于提供连续使用体验。 这些数据主要保存在本地设备，不用于上传或共享。

这不是运营话术，而是技术事实对外披露。

7. 技术结论

Preferences 简单，但不能随便写。一个可维护的 HarmonyOS 应用，应该把持久化放在服务层，页面只处理状态展示和用户交互。这样后续加清空数据、导入导出、版本迁移才有空间。。再帮帮孩子吧，我这个应用用代码一个一个敲出来的，帮忙到应用市场下载一个评论一下体验一哈，谢谢支持，转盘决定吧