HarmonyOS应用实战-启示散页-72-多窗口编辑别互相覆盖草稿：给每个窗口分配 draftSessionId

HarmonyOS 应用实战 72：多窗口编辑别互相覆盖草稿：给每个窗口分配 draftSessionId

分屏、多窗口和任务切换在 HarmonyOS 上很常见。题库编辑页如果只把“是否修改过”存在页面里，两个窗口同时打开同一副牌时就会出现一个很隐蔽的问题：A 窗口先保存成功，B 窗口后保存旧草稿，最后把 A 的修改盖掉。

这篇只处理一个问题：DeckEditPage这种“先加载、再本地编辑、最后一次性提交”的页面，如何补一条可解释的草稿版本链。现有工程已经有originalSig、updatedAt、DeckService.save和AppStorageKey.LastDeckUpdateAt，缺的不是再加一个按钮，而是保存前的版本闸门。

先看整体结论图，后面三张图会分散放在对应小节里，不把配图挤在文章开头。

这篇解决什么

读完之后，应该能把这个问题拆成四个可落地的动作：

这里不讨论复杂协同编辑。题库答案是短文本列表，直接做实时合并会带来顺序、删除、空行、超长答案等新问题。更稳的做法是：先阻止覆盖，再给用户明确的处理选择。

现有编辑链路：页面能判断脏状态，但不知道版本是否过期

当前DeckEditPage的加载逻辑很清楚：读取Deck，把答案转成页面可编辑的EditableAnswer，再用originalSig保存打开时的文本快照。

interfaceEditableAnswer{key:string;text:string;}privateasyncload():Promise<void>{if(!this.deckId){return;}this.loading=true;try{constdeck:Deck|null=awaitDeckService.get(this.deckId);if(!deck){promptAction.showToast({message:'题库不存在'});this.pathStack.pop();return;}this.deckName=deck.name;this.originalName=deck.name;this.builtIn=deck.builtIn;this.answers=deck.answers.map((a:Answer):EditableAnswer=>{conste:EditableAnswer={key:a.id,text:a.text};returne;});this.originalSig=this.signature();}finally{this.loading=false;}}

这段代码已经解决了“页面有没有改过”的问题，但它只比较当前窗口自己的前后状态。另一个窗口有没有把同一副牌改成新版本，页面本身并不知道。

保存入口：当前是一次性提交，没有版本闸门

继续看保存入口。现在页面把deckId、deckName、answers组装成SaveDeckPayload，直接交给DeckService.save。

privateasynconSave():Promise<void>{if(this.saving){return;}if(this.builtIn){promptAction.showToast({message:'内置题库不可修改'});return;}this.saving=true;try{constpayload:SaveDeckPayload={id:this.deckId,name:this.deckName,answers:this.answers.map((a:EditableAnswer):string=>a.text)};awaitDeckService.save(payload);promptAction.showToast({message:'已保存'});this.originalSig=this.signature();this.originalName=this.deckName;this.editing=false;this.pathStack.pop();}finally{this.saving=false;}}

这个实现适合单窗口编辑，也适合用户自己连续修改同一个页面。但在两个窗口同时打开同一副牌时，它缺少一个输入：这次提交基于哪一个updatedAt。

覆盖是怎么发生的

多窗口覆盖不是“保存按钮点太快”这么简单，它通常按下面的顺序出现。

所以保存前不能只问“当前页面是否 dirty”，还要问“仓储里的牌组是否还是我打开时的那一版”。这就是baseUpdatedAt的价值。

草稿状态：draftSessionId 不是业务 id

建议在编辑页增加两个字段：draftSessionId用来标识这次编辑会话，baseUpdatedAt用来记录打开页面时的牌组版本。它们不替代deckId，也不写进最终牌组。

interfaceDeckEditDraftState{draftSessionId:string;deckId:string;baseUpdatedAt:number;originalSignature:string;dirty:boolean;}functioncreateDraftSessionId(deckId:string):string{returndeckId+'_'+Date.now().toString();}

这两个字段的职责要分开：

加载时记录基线版本

页面加载成功后，除了当前已经写入的originalSig，还应该记录deck.updatedAt。这一步必须发生在DeckService.get返回之后，不能提前用当前时间代替。

@StateprivatedraftSessionId:string='';@StateprivatebaseUpdatedAt:number=0;@StateprivateconflictMessage:string='';privateapplyLoadedDeck(deck:Deck):void{this.deckName=deck.name;this.originalName=deck.name;this.builtIn=deck.builtIn;this.answers=deck.answers.map((a:Answer):EditableAnswer=>{constitem:EditableAnswer={key:a.id,text:a.text};returnitem;});this.originalSig=this.signature();this.baseUpdatedAt=deck.updatedAt;this.draftSessionId=createDraftSessionId(deck.id);this.conflictMessage='';}

这里没有把draftSessionId存进 Preferences，因为它只属于当前编辑窗口。重启应用之后草稿会话自然失效，页面应该重新加载牌组并生成新的基线版本。

服务层保存：比较 updatedAt，不让旧草稿直写

真正的版本比较应该放在DeckService。页面可以传baseUpdatedAt，但不能自己读仓储、比较版本、再决定是否保存。否则列表页、导入页、批量编辑页以后都会复制一套规则。

建议把“带版本保存”做成服务层方法，返回明确结果，而不是只用异常承载所有业务分支。

interfaceVersionedSaveDeckPayloadextendsSaveDeckPayload{baseUpdatedAt:number;draftSessionId:string;}interfaceDeckSaveConflict{deckId:string;draftSessionId:string;baseUpdatedAt:number;latestUpdatedAt:number;latestName:string;}interfaceVersionedSaveResult{ok:boolean;summary?:DeckSummary;conflict?:DeckSaveConflict;}

这个结果模型只表达三件事：保存成功、发生冲突、冲突对应的最新版本。页面拿到结果后再决定展示“刷新后重新编辑”还是“另存为新牌组”。

saveWithVersion：复用现有校验，新增冲突分支

现有DeckService.save已经负责名称、答案数量、答案长度和最终写入。不要把这些规则搬到新方法里重新写一遍。更合适的方式是：先做版本闸门，通过后继续调用原保存方法。

asyncsaveWithVersion(payload:VersionedSaveDeckPayload):Promise<VersionedSaveResult>{if(payload.id){constlatest:Deck|null=awaitDeckRepository.loadDeck(payload.id);if(!latest){thrownewError('题库不存在，无法保存');}if(latest.builtIn){thrownewError('内置题库不可修改');}if(latest.updatedAt!==payload.baseUpdatedAt){constconflict:DeckSaveConflict={deckId:latest.id,draftSessionId:payload.draftSessionId,baseUpdatedAt:payload.baseUpdatedAt,latestUpdatedAt:latest.updatedAt,latestName:latest.name};return{ok:false,conflict};}}constsummary:DeckSummary=awaitthis.save(payload);return{ok:true,summary};}

这段代码的关键点是“失败不写入”。一旦发现latest.updatedAt已经变了，直接返回冲突结果，不尝试自动合并答案列表。对于答案列表这种有顺序、有删除、有长度上限的数据，自动合并很容易制造第二个问题。

页面冲突处理：提示刷新，不偷偷覆盖

页面保存时只需要补齐两个字段，然后根据结果分支展示反馈。冲突时不要调用pathStack.pop()，否则用户会以为保存成功。

privateasynconSave():Promise<void>{if(!this.canSave()){return;}this.saving=true;try{constpayload:VersionedSaveDeckPayload={id:this.deckId,name:this.deckName,answers:this.answers.map((a:EditableAnswer):string=>a.text),baseUpdatedAt:this.baseUpdatedAt,draftSessionId:this.draftSessionId};constresult:VersionedSaveResult=awaitDeckService.saveWithVersion(payload);if(!result.ok&&result.conflict){this.conflictMessage='这副题库已在其他窗口更新，请刷新后再保存';return;}promptAction.showToast({message:'已保存'});this.originalSig=this.signature();this.editing=false;this.pathStack.pop();}finally{this.saving=false;}}

冲突提示不要只写“保存失败”。用户需要知道下一步是什么：刷新、放弃本地草稿、或者另存为新牌组。第一版可以先只做刷新和放弃，后续再补另存。

刷新冲突：重新加载前先保护用户输入

发生冲突后，直接覆盖页面输入会让用户更困惑。更稳的处理是保留当前草稿，同时提供一个显式刷新入口。

@BuilderconflictBanner(){if(this.conflictMessage){Column({space:8}){Text(this.conflictMessage).fontSize(AppFont.body).fontColor(AppColor.danger)Row({space:12}){Text('刷新最新版本').fontColor(AppColor.goldWarm).onClick(()=>{this.load().catch((e:Error)=>{hilog.warn(DOMAIN,TAG,'reload after conflict failed: %{public}s',e.message);});})Text('继续查看草稿').fontColor(AppColor.creamMuted)}}.padding(12).border({width:1,color:AppColor.danger}).borderRadius(AppRadius.md)}}

这个入口的目标不是做复杂合并，而是避免静默丢数据。用户至少能看见“我现在编辑的是旧版本”，再决定是否刷新。

验证路径：要验证成功，也要验证拒绝写入

只验证单窗口保存是不够的。这个改动真正要证明的是：旧草稿不会覆盖新版本。

本地可以先用rg把落点查清楚：

Write-Host"查看编辑页现有保存链路"rg-n"originalSig|baseUpdatedAt|draftSessionId|onSave|DeckService.save""D:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\pages\DeckEditPage.ets"Write-Host"查看服务层是否已有版本比较"rg-n"updatedAt|saveWithVersion|LastDeckUpdateAt|save\\(""D:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\services\DeckService.ets"

这些命令只能确认源码落点。多窗口覆盖需要在模拟器、真机或 DevEco 多实例场景里走完整交互，不能只看 Markdown 或静态脚本结论。

常见问题

收口

第 72 篇的核心不是“加一个草稿对象”，而是把编辑页的提交链路补完整：打开时记录基线版本，保存时由服务层比较最新版本，冲突时页面给用户明确选择。这样多窗口、分屏和后台返回都不会把旧草稿静默写回仓储。

这篇里的saveWithVersion属于建议补强，不是当前工程已经存在的方法。当前工程已经具备updatedAt、originalSig和DeckService.save这些基础，只要把版本闸门放对位置，就能避免旧窗口覆盖新内容。