文章目录前言为什么这个问题经常被写乱什么适合放进 preferences先把页面目标想清楚完整 ArkTS 示例把关键代码一段段拆开保存时机怎么选新手最容易踩的坑放进真实项目还要补什么写在最后前言草稿数据通常不大但对用户很重要。写到一半退出页面、应用被回收、网络提交失败用户都希望内容还能找回来。HarmonyOS7 里preferences很适合保存这种轻量键值数据。但它不是数据库也不是万能缓存。我的习惯是提前想清楚三件事恢复什么、什么时候保存、什么时候清理。草稿存储要及时但不能无边界。为什么这个问题经常被写乱preferences 存草稿刚刚好 这类内容很容易被写成“代码能跑就算讲完了”但对初学者来说这恰恰是最不够的地方。真正让人卡住的往往不是某个组件名记不住而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。所以这篇文章不只想给你一个能跑的例子更想把背后的判断过程讲清楚。你只要把这个判断过程吃透后面自己改页面、补需求、查问题时心里会稳很多。什么适合放进 preferences笔记草稿是典型场景标题和正文都是字符串数据量小恢复价值高。数据是否适合说明草稿标题适合小而明确草稿正文适合短文本长文或富文本要另选方案图片列表不适合结构和体积都偏重上次选择适合比如排序方式、开关配置我会把preferences当成轻量记事本而不是缓存层。只要数据开始变大、变复杂就应该重新考虑存储方案。先把页面目标想清楚在真正写代码之前先别急着盯着 API。更有用的做法是先想清楚这个页面到底想解决什么问题用户最在意的反馈是什么哪些状态必须一直保持一致。当你先把这条主线想明白再回头看组件和状态设计很多选择都会顺理成章。对小白来说这一步尤其重要因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。完整 ArkTS 示例import{preferences}fromkit.ArkDataEntryComponentstruct DraftPreferencePage{Statetitle:stringStatecontent:stringStatestatus:string草稿未加载privatestore:preferences.Preferences|undefinedundefinedasyncaboutToAppear():Promisevoid{this.storeawaitpreferences.getPreferences(getContext(this),noteDraft)this.titleawaitthis.store.get(title,)asstringthis.contentawaitthis.store.get(content,)asstringthis.status已恢复本地草稿}privateasyncsaveDraft():Promisevoid{if(!this.store){return}awaitthis.store.put(title,this.title)awaitthis.store.put(content,this.content)awaitthis.store.flush()this.status草稿已保存}privateasyncclearDraft():Promisevoid{if(!this.store){return}awaitthis.store.delete(title)awaitthis.store.delete(content)awaitthis.store.flush()this.titlethis.contentthis.status草稿已清空}build(){Column({space:12}){Text(笔记草稿).fontSize(22).fontWeight(FontWeight.Bold).width(100%)TextInput({placeholder:标题,text:this.title}).onChange((value:string){this.titlevalue})TextArea({placeholder:写点内容...,text:this.content}).height(180).onChange((value:string){this.contentvalue})Text(this.status).fontSize(12).fontColor(#777777).width(100%)Row({space:10}){Button(保存草稿).layoutWeight(1).onClick((){this.saveDraft()})Button(清空).layoutWeight(1).backgroundColor(#F0F2F5).fontColor(#333333).onClick((){this.clearDraft()})}.width(100%)}.padding(16)}}把关键代码一段段拆开aboutToAppear()里恢复草稿。页面出现时先读本地内容用户能直接接着写不需要自己重新输入。saveDraft()里put()之后调用flush()。这一步很关键很多人只写put()以为数据已经稳了但没有及时落盘异常退出时就可能丢。clearDraft()同时清理本地存储和页面状态。只删本地不清 UI用户会以为还没删只清 UI 不删本地下次打开又会恢复旧内容。store用可选类型是因为它需要异步初始化。按钮触发时如果还没准备好直接返回比强行使用更稳。保存时机怎么选示例里用按钮手动保存适合教程理解。真实项目中可以在离开页面、输入停顿一段时间、提交失败时保存。不要每输入一个字符就落盘频率太高没有必要。提交成功后要清理草稿。否则用户下次打开编辑页看到的可能是上一次已经发布成功的内容。新手最容易踩的坑这一类示例最容易让人产生错觉界面出来了就以为已经掌握了。其实真正容易出问题的地方通常都在效果之外比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。所以你练这篇内容时别只看“现在能不能跑”还要继续看“以后好不好改”。能把这个习惯养起来你写出来的页面会比单纯照着示例拼出来的页面稳很多。放进真实项目还要补什么示例代码的重点是把核心思路讲明白所以很多工程化细节会故意省掉。真正落到项目里时你通常还要继续补接口联动、异常处理、边界保护、资源抽离以及和其他页面状态之间的配合。比较稳的做法是分三步走先把结构和职责立住再把真实业务接进去最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”而是真的更接近可以长期维护的业务代码。写在最后preferences存草稿刚刚好轻、快、代码也不复杂。关键是别贪心别把大对象和复杂列表都塞进去。保存和清理边界写清楚草稿功能就很稳。