第39篇设置开关退出就复原用偏好写队列和回滚状态兜住摘要设置页开关最容易被写成State一改就完事。实际项目里用户快速连点、离开页面、写入失败、重启应用都会暴露问题UI 显示已开启持久化里还是旧值。更稳的做法是让设置写入走串行队列页面可以乐观展示但失败必须回滚并用重启验证证明真的保存成功。我处理过一个提醒开关问题用户打开“每日提醒”页面显示已开启退出再进又变回关闭。日志里没有崩溃因为 UI 状态确实变了只是 Preferences 写入被后一次旧值覆盖。更麻烦的是用户快速点三次最后界面和持久化各拿一个值。这个问题不能靠“加个 await”随便修要把写入路径收成一个队列。这篇文章解决四个实际问题区分页面乐观状态和已落盘状态。用 SettingWriteQueue 串行处理同一个 key 的写入。写入失败时回滚 UI并给用户可理解提示。用退出重进和杀进程重启验证持久化真实生效。先确认复原发生在哪个时刻设置复原可能发生在返回页面时也可能是杀进程重启后。两个现象对应的根因不同不能只看开关 UI。位置现象风险处理方向返回页面复原页面重新读取旧缓存写入还没完成等待写入确认或展示保存中重启后复原持久化失败只改了内存状态统一写入 Preferences快速连点错乱并发写同一个 key后完成的旧值覆盖新值串行队列写入失败无提示catch 后吞错用户以为保存成功失败回滚这一步的价值是先把问题放回运行链路。只要能确认问题停在哪个位置后面就不用靠猜测改页面。页面只能发意图不能直接散写偏好设置项看起来简单但长期维护时会有默认值、迁移、校验和失败回滚。页面直接写 Preferences 会让这些逻辑散得到处都是。模块应该负责不应该负责SettingsPage展示值、保存中、错误文案Preferences APISettingsService设置项校验和保存流程具体 UI 布局SettingWriteQueue同 key 串行写入业务默认值PreferenceStore读写持久化连点策略Migration旧 key 到新 key页面事件边界定清后代码就不会在页面、服务和回调之间来回复制同一段判断。后续新增场景也能先判断应该落在哪一层。设置状态要有 pending 标记exportinterfaceSettingItemState{key:stringvalue:booleanpersistedValue:booleanpending:booleanerrorText:string}exportfunctioncreateSettingState(key:string,value:boolean):SettingItemState{return{key,value,persistedValue:value,pending:false,errorText:}}value是页面当前展示persistedValue是最后一次确认落盘的值。失败时页面能回滚到真实持久化状态而不是随便猜一个默认值。这类模型最好放在models或common中页面、Service 和仓储都使用同一份类型避免各层用字符串互相猜。写队列保证同一个 key 顺序执行exportclassSettingWriteQueue{privatejobs:Mapstring,PromisevoidnewMap()enqueue(key:string,task:()Promisevoid):Promisevoid{constpreviousthis.jobs.get(key)??Promise.resolve()constnextprevious.then(task).finally((){if(this.jobs.get(key)next){this.jobs.delete(key)}})this.jobs.set(key,next)returnnext}}队列按 key 串行不会让两个提醒开关互相阻塞但能保证同一个 key 的后一次操作不会被更早的写入覆盖。Service 的目标不是把所有逻辑都塞进去而是把跨页面、跨生命周期或需要持久化的判断集中起来。页面只表达用户动作。页面先乐观更新再等确认Componentstruct ReminderSettingRow{Stateitem:SettingItemStatecreateSettingState(daily_reminder,false)privateservice:SettingsServicecreateSettingsService()asynctoggleReminder(nextValue:boolean):Promisevoid{constbeforethis.item.persistedValuethis.item{...this.item,value:nextValue,pending:true,errorText:}constsavedawaitthis.service.saveBoolean(this.item.key,nextValue)if(!saved){this.item{...this.item,value:before,pending:false,errorText:保存失败请重试}return}this.item{...this.item,persistedValue:nextValue,pending:false,errorText:}}}乐观更新能让交互及时但pending和回滚不能省。否则用户看到的是“已开启”持久化里却可能还是关闭。页面层要控制展示和交互节奏但不应该拥有底层事实。这样页面重建、横竖屏变化或返回前台时都能重新从 Service 拿到可信结果。SettingsService 统一读写默认值exportclassSettingsService{constructor(privatereadonlystore:PreferenceStore,privatereadonlyqueue:SettingWriteQueue){}asyncloadBoolean(key:string,defaultValue:boolean):Promiseboolean{constvalueawaitthis.store.getBoolean(key)returnvalue??defaultValue}asyncsaveBoolean(key:string,value:boolean):Promiseboolean{returnthis.queue.enqueue(key,async(){awaitthis.store.putBoolean(key,value)awaitthis.store.flush()}).then(()true).catch(()false)}}读默认值和写入确认都在 Service 层。页面不用知道是否需要 flush也不会因为多个页面同时写同一个 key 出现竞争。实际项目里很多问题不是第一次进入页面暴露而是在冷启动、返回前台、页面重建或回调晚到时暴露。把这段生命周期补上修复才算闭环。失败路径要回滚而不是假装成功情况页面表现工程处理写入失败回滚到 persistedValue展示保存失败用户快速连点同 key 排队最后一次结果一致读取旧 key迁移后删除旧 key避免重启读回旧值页面离开时 pending保留保存中提示或禁用返回不要直接丢状态兜底路径不是可有可无。用户遇到异常时页面至少要给出当前状态、可执行动作和可排查线索。排查时找散写偏好rg-nputBoolean|getBoolean|Preferences|flush|daily_reminderentry features common rg-nState.*reminder|persistedValue|pending|SettingWriteQueueentry features common rg-nonClick|onChange|Toggle|Switchentry features common第一组命令找旧路径第二组命令找新边界第三组命令看生命周期或回调位置。命中后不要只看字段名要判断它是否仍在直接改页面状态。验证清单验证项预期结果打开开关后返回再进仍保持新值杀进程重启仍读取到新值快速连点三次最终 UI 和持久化一致模拟写入失败UI 回滚并显示错误旧版本迁移旧 key 不再覆盖新 key这些验证最好在真机或模拟器里按顺序走一遍。只看源码很难发现冷启动、重启和回调晚到这类问题。常见问题和处理方式现象常见原因处理方式退出就复原只改 State必须走 SettingsService偶现反向并发写入乱序同 key 串行队列失败无感catch 后吞错回滚并提示重启读旧值默认值和旧 key 散落集中迁移和读取如果现象没有出现在表里仍然建议按“输入来源 - 中间状态 - 持久化或页面展示 - 失败兜底”的顺序排查。小结设置项要把显示和落盘分清开关状态不是点一下就结束。页面可以先展示用户选择但服务层必须串行写入、确认落盘、失败回滚最后用重启验证。这样设置页才不会出现看似保存成功、实际重进复原的问题。| 默认值和旧 key 散落 | 集中迁移和读取 |如果现象没有出现在表里仍然建议按“输入来源 - 中间状态 - 持久化或页面展示 - 失败兜底”的顺序排查。小结设置项要把显示和落盘分清开关状态不是点一下就结束。页面可以先展示用户选择但服务层必须串行写入、确认落盘、失败回滚最后用重启验证。这样设置页才不会出现看似保存成功、实际重进复原的问题。