在写到稍微复杂一点的功能时，我第一次真正遇到了一个很具体的问题：有些数据不能只存在内存里。页面一刷新、应用一关闭，它就消失了，但实际使用中，这些信息是应该被“记住”的。

比如一些很典型的场景，用户是否开启某个功能、上一次的配置选项，或者一些简单的标记位。这时候就会开始找本地存储能力，对应在 HarmonyOS 里看到的是这样一个入口：

import dataPreferences from '@ohos.data.preferences'

第一次看到这个模块名的时候，其实就有点直觉上的提示了。它没有叫 storage，也没有叫 database，而是叫 preferences，这个命名本身就很偏向“偏好设置”。后来用了一段时间之后，发现这个直觉基本是对的。

慢慢会意识到，这个东西的核心能力其实很单一，它更像是一个长期存在的键值表。你用一个 key 存一个值，再用同一个 key 把它取出来。整个模型非常简单，没有复杂结构，也没有关系设计。如果硬要类比，其实很接近 Android 里的 SharedPreferences，本质上是在解决同一类问题。

一开始我会下意识把它当成“本地存储方案”，甚至有点像数据库的轻量替代。但这种理解很快就会遇到问题。因为一旦你试图往里面放稍微复杂一点的数据，就会发现用起来并不自然。结构一复杂，就需要自己做序列化；数据一多，管理就开始变得混乱；如果还想做筛选或者按条件读取，那基本就已经超出它的能力范围了。

这时候再回头看，其实问题不在工具本身，而在一开始的定位就错了。Preferences 并不是用来解决“数据管理”的，而是用来解决“状态持久化”的。它更适合那些零散的、小规模的、和状态强相关的数据，而不是一整块业务数据。

Preferences 不是用来“存数据”的，而是用来“记住一些状态”的。

这个认知一旦建立起来，后面在使用本地存储时，很多选择就会变得清晰很多。