第7篇｜退出登录后旧状态还在：把持久化键集中水合和清理

第7篇｜退出登录后旧状态还在：把持久化键集中水合和清理

摘要：退出登录后还看到旧头像、旧收藏数、旧课程进度，这类问题很容易被当成页面刷新不及时。实际根因通常是持久化键散落在各处：启动时谁负责水合不清楚，退出时谁负责清理也不清楚。我的做法是把持久化键集中维护，启动时统一写安全默认值，退出时按同一份清单清理。

做鸿蒙应用时，AppStorage、Preferences、本地缓存经常一起出现。它们本身没问题，问题在于项目后期页面越来越多，状态键也越来越散。某个页面新增了favoriteCourses，另一个页面新增了profileDraft，退出登录时只清了 token，旧状态就会继续留在页面上。

这篇文章解决四个具体问题：

1. 为什么退出登录不能只删 token。
2. 如何集中维护持久化键。
3. 启动水合和退出清理怎样复用同一份清单。
4. 页面如何安全读取@StorageLink状态。

退出登录不是一个按钮事件，而是一条状态链路

退出登录至少会影响四类状态：

所以退出登录不能只写成clearToken()。它应该是一个明确的重置流程，覆盖身份、业务缓存和页面状态。

先把键名集中起来

我会先建一个PersistKeys，集中列出需要水合和清理的键：

// storage/PersistKeys.etsexportconstPersistKeys={token:'auth_token',userId:'auth_user_id',profile:'profile_state',favoriteCourses:'favorite_courses',learningProgress:'learning_progress',searchKeyword:'search_keyword'}asconstexportconstLoginScopedKeys:string[]=[PersistKeys.token,PersistKeys.userId,PersistKeys.profile,PersistKeys.favoriteCourses,PersistKeys.learningProgress,PersistKeys.searchKeyword]

这份清单的价值在于可复用。启动水合、退出清理、重置测试数据都可以引用同一组键，避免某个新状态只加在页面里，忘了加到清理流程里。

启动时先写安全默认值

页面挂载时，@StorageLink读到的值可能还没准备好。为了避免首屏访问未准备状态，我会在应用启动阶段先写默认值：

// storage/AppStorageBootstrap.etsimport{PersistKeys}from'./PersistKeys'exportclassAppStorageBootstrap{statichydrateDefaults():void{AppStorage.setOrCreate(PersistKeys.token,'')AppStorage.setOrCreate(PersistKeys.userId,'')AppStorage.setOrCreate(PersistKeys.profile,{})AppStorage.setOrCreate(PersistKeys.favoriteCourses,[])AppStorage.setOrCreate(PersistKeys.learningProgress,{})AppStorage.setOrCreate(PersistKeys.searchKeyword,'')}}

这一步不是读取真实数据，而是先保证页面读到的是安全结构。比如数组就是数组，对象就是对象，字符串就是字符串。页面后续可以等持久化数据加载完成再更新。

AbilityStage 里完成基础水合

基础水合适合放在启动早期，保证页面创建前已有默认值：

// entryability/EntryAbility.etsimport{AppStorageBootstrap}from'../storage/AppStorageBootstrap'onCreate(want:Want,launchParam:AbilityConstant.LaunchParam):void{AppStorageBootstrap.hydrateDefaults()console.info('[storage] default app storage hydrated')}

如果项目里还有 Preferences 读取，可以在默认值之后异步补真实值。关键是不要让页面第一次挂载时面对undefined，尤其是数组、对象这类会被.length或属性访问触发异常的值。

退出登录用统一服务清理

退出登录时，不要在页面里一个个删。用一个服务统一清理：

// service/LogoutService.etsimport{LoginScopedKeys,PersistKeys}from'../storage/PersistKeys'exportclassLogoutService{staticasynclogout(preferences:dataPreferences.Preferences):Promise<void>{for(constkeyofLoginScopedKeys){awaitpreferences.delete(key)}awaitpreferences.flush()AppStorage.set(PersistKeys.token,'')AppStorage.set(PersistKeys.userId,'')AppStorage.set(PersistKeys.profile,{})AppStorage.set(PersistKeys.favoriteCourses,[])AppStorage.set(PersistKeys.learningProgress,{})AppStorage.set(PersistKeys.searchKeyword,'')}}

这段代码同时处理两层：持久化存储和运行时状态。只删 Preferences 不够，因为当前页面可能还在读AppStorage；只改AppStorage也不够，因为下次启动可能又把旧值读回来。

页面读取状态要有安全方法

页面里不要直接假设@StorageLink一定是你想要的类型。尤其是在 Builder 里，直接对不确定对象做字符串拼接或.length，很容易把状态问题变成运行时崩溃。

// pages/ProfilePage.ets@Entry@Componentstruct ProfilePage{@StorageLink('favorite_courses')favoriteCourses:string[]=[]@StorageLink('profile_state')profile:Record<string,Object>={}getFavoriteCount():number{if(!Array.isArray(this.favoriteCourses)){return0}returnthis.favoriteCourses.length}getNickname():string{constvalue=this.profile['nickname']returntypeofvalue==='string'&&value.length>0?value:'未登录用户'}build(){Column(){Text(this.getNickname())Text(`收藏课程：${this.getFavoriteCount()}`)}}}

这里用普通方法返回安全值，页面展示层就不用面对不确定结构。退出登录、切账号、清空数据后，页面仍然能稳定渲染。

退出后要处理路由回退

状态清掉以后，如果用户还停留在详情页或个人中心深层页面，也可能看到不该出现的界面。退出流程应该把页面带回明确入口：

// pages/ProfileSettingsPage.etsasyncfunctionconfirmLogout(preferences:dataPreferences.Preferences):Promise<void>{awaitLogoutService.logout(preferences)router.replaceUrl({url:'pages/LoginPage'})}

这里用replaceUrl是为了避免用户按返回键又回到登录前的页面。退出登录不仅是数据清理，也包含导航栈收口。

我会怎样复查退出流程

我一般按下面场景走：

1. 登录账号 A，进入个人中心、收藏页、学习进度页。
2. 执行退出登录，确认头像、昵称、收藏、进度全部清空。
3. 按返回键，确认不会回到账号 A 的页面。
4. 关闭应用再打开，确认旧状态没有从持久化里恢复。
5. 登录账号 B，确认不会看到账号 A 的业务缓存。

这套复查能覆盖运行时状态、持久化状态、导航栈和切账号场景。

常见问题和处理方式

小结：状态清理要和状态创建使用同一份清单

退出登录要稳定，关键不是多写几个delete，而是让状态创建和状态清理都围绕同一份键名清单。启动先水合安全默认值，页面用方法读取安全值，退出时同时清持久化和运行时状态，最后收掉导航栈。这样旧账号状态就不会在新会话里冒出来。