HarmonyOS 应用实战 98：隐私弹窗别挡住恢复路径，先保证可退出和可重开

隐私弹窗最容易被写成“首次启动弹一次”。这样做上线前看起来没问题，但遇到备份恢复、版本升级、用户拒绝后再次进入，就会暴露两个风险：没有明确同意记录，或者弹窗挡住了退出和恢复路径。

“答案之书”当前工程里，应用级偏好有firstLaunchDone，但没有独立的隐私同意状态。第 98 篇要说清楚这个边界：首次启动完成不等于用户同意隐私协议；隐私状态应该有版本、同意时间、拒绝出口和再次打开入口。

当前偏好键只覆盖启动状态

libraryHAR/src/main/ets/models/AppPreferences.ets当前定义如下：

exportinterfaceAppPreferences{schemaVersion:number;currentDeckId:string;firstLaunchDone:boolean;}exportclassAppPrefKey{staticreadonlySchemaVersion:string='schemaVersion';staticreadonlyCurrentDeckId:string='currentDeckId';staticreadonlyFirstLaunchDone:string='firstLaunchDone';staticreadonlyLastSeededVersion:string='lastSeededVersion';}

这里的firstLaunchDone只能说明“首次启动流程是否完成”。它不能说明用户看过哪一版隐私文本，不能说明用户何时同意，也不能支持撤回或重新查看。

启动链路也没有隐私拦截点

EntryAbility当前启动时会初始化 Preferences 并运行SeedLoader，然后加载首页：

try{awaitPreferencesStore.init(ctx);awaitSeedLoader.run(ctx);}catch(err){hilog.error(DOMAIN,'testTag','bootstrap failed: %{public}s',(errasError).message);}windowStage.loadContent('pages/Index',(err)=>{if(err.code){hilog.error(DOMAIN,'testTag','Failed to load the content. Cause: %{public}s',JSON.stringify(err));return;}hilog.info(DOMAIN,'testTag','Succeeded in loading the content.');});

这段代码说明当前应用更关注“数据能否就绪”。如果要加隐私弹窗，不能简单塞在首页最上层遮住所有内容，而要设计清楚：未同意时能退出，已同意后能进入业务，恢复或升级后能重新判断协议版本。

为什么不能用 firstLaunchDone 代替同意记录

两者的含义不同：

如果把隐私同意混在firstLaunchDone里，用户恢复备份后可能直接进入业务页；协议更新后也无法判断是否需要重新展示。这不是 UI 问题，而是状态语义不清。

建议新增独立 ConsentRecord

下面是建议补强模型，不表示当前工程已经存在：

exportinterfacePrivacyConsentRecord{accepted:boolean;policyVersion:string;acceptedAt:number;source:'first_open'|'settings'|'restore';}exportclassPrivacyPrefKey{staticreadonlyConsentRecord:string='privacyConsentRecord';}

policyVersion要和隐私文本版本绑定。只存一个 boolean 不够，因为协议内容更新后，程序需要知道旧同意是否还能继续使用。source也不是装饰字段，它能帮助排查“用户是在首次打开同意，还是恢复后重新确认”。

用服务封住读写规则

隐私状态不建议散落在页面里直接读写 Preferences。可以用一个服务集中处理：

classPrivacyConsentServiceImpl{asyncload():Promise<PrivacyConsentRecord|null>{returnawaitPreferencesStore.getJson<PrivacyConsentRecord|null>(PrefStoreName.App,PrivacyPrefKey.ConsentRecord,null);}asyncisAccepted(policyVersion:string):Promise<boolean>{constrecord:PrivacyConsentRecord|null=awaitthis.load();return!!record&&record.accepted&&record.policyVersion===policyVersion;}asyncaccept(policyVersion:string,source:PrivacyConsentRecord['source']):Promise<void>{constrecord:PrivacyConsentRecord={accepted:true,policyVersion,acceptedAt:Date.now(),source};awaitPreferencesStore.setJson(PrefStoreName.App,PrivacyPrefKey.ConsentRecord,record);}}

页面不应该自己拼 key，也不应该自己判断版本兼容。页面只负责展示协议、同意、拒绝、重新打开；服务负责状态含义和写入位置。

弹窗要有拒绝出口

隐私弹窗不应只提供“同意”。用户拒绝时，至少要能退出当前业务入口，不能被遮罩卡死：

@BuilderfunctionPrivacyGate(){Column({space:16}){Text('隐私说明').fontSize(20).fontWeight(FontWeight.Medium)Text('请阅读并确认本地题库、收藏和提问历史的使用方式。').fontSize(14)Row({space:12}){Button('不同意').onClick(()=>this.exitApp())Button('同意并进入').onClick(()=>this.acceptAndEnter())}}}

exitApp()在真实工程里可以调用 Ability 上下文结束当前页面或退回安全入口。关键是保留明确出口，而不是让用户只能点同意才能继续操作。

恢复后要重新判断，而不是沿用旧界面状态

备份恢复会改变 Preferences，隐私状态也可能被带回来。恢复链路完成后，应该重新读取同意记录：

asyncfunctionafterRestore(policyVersion:string):Promise<void>{constok:boolean=awaitPrivacyConsentService.isAccepted(policyVersion);if(!ok){AppStorage.setOrCreate('privacyGateVisible',true);return;}AppStorage.setOrCreate('privacyGateVisible',false);}

这段逻辑的重点是“恢复后重新判断”。不要因为当前页面已经在业务态，就默认恢复后的偏好仍然可信。尤其是跨版本恢复时，协议版本必须重新对齐。

和当前启动流程怎么配合

更稳的接入顺序是：

1. EntryAbility初始化PreferencesStore。
2. SeedLoader保证默认题库和currentDeckId可用。
3. 首页或统一入口读取PrivacyConsentService.isAccepted()。
4. 未同意时展示可退出的隐私入口。
5. 同意后写入policyVersion + acceptedAt，再开放业务操作。

这样做不会阻断启动自愈，也不会把同意状态和默认题库播种混在一起。数据可以先就绪，业务入口再根据隐私状态决定是否可用。

验证路径

静态确认：

rg-n"FirstLaunchDone|PrivacyConsent|ConsentRecord|policyVersion|acceptedAt"`"D:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHAR\src\main\ets"`"D:\ProgramData\huawei\lesson\The_Book_of_Answers\entry\src\main\ets"

交互回归：

本文没有实际改 HarmonyOS 工程代码，也没有执行真机隐私流程；这些是落地方案时必须补跑的验证项。

常见问题

隐私流程出问题时，通常不是弹窗样式不够明显，而是状态语义没有分清。排查时先确认当前读取的是启动标记、协议版本，还是用户同意记录；再看拒绝和恢复路径是否能走通。

收口

隐私弹窗不是首次启动装饰。当前工程里的firstLaunchDone只能表示启动流程，不能替代隐私同意。要让隐私流程可维护，就把同意状态独立成PrivacyConsentRecord，保留版本、时间、来源、拒绝出口和恢复后的重新判断。

这条边界一旦立住，后续扩展会简单很多：协议文本更新时只比较policyVersion，备份恢复后只重新读取同意记录，用户拒绝时只退回安全入口。业务页不用理解隐私状态的存储细节，也不会因为一个启动标记被误用而绕过用户选择。