HarmonyOS 应用实战 72多窗口编辑别互相覆盖草稿给每个窗口分配 draftSessionId分屏、多窗口和任务切换在 HarmonyOS 上很常见。题库编辑页如果只把“是否修改过”存在页面里两个窗口同时打开同一副牌时就会出现一个很隐蔽的问题A 窗口先保存成功B 窗口后保存旧草稿最后把 A 的修改盖掉。这篇只处理一个问题DeckEditPage这种“先加载、再本地编辑、最后一次性提交”的页面如何补一条可解释的草稿版本链。现有工程已经有originalSig、updatedAt、DeckService.save和AppStorageKey.LastDeckUpdateAt缺的不是再加一个按钮而是保存前的版本闸门。先看整体结论图后面三张图会分散放在对应小节里不把配图挤在文章开头。这篇解决什么读完之后应该能把这个问题拆成四个可落地的动作动作目的落点打开编辑页时记录基线版本知道这份草稿基于哪一版牌组DeckEditPage.load()每个编辑窗口生成独立草稿 id排查日志和冲突提示可追踪页面状态保存前读取最新牌组版本阻止旧草稿覆盖新内容DeckService冲突时不自动合并避免页面猜用户真实意图编辑页提示刷新或另存这里不讨论复杂协同编辑。题库答案是短文本列表直接做实时合并会带来顺序、删除、空行、超长答案等新问题。更稳的做法是先阻止覆盖再给用户明确的处理选择。现有编辑链路页面能判断脏状态但不知道版本是否过期当前DeckEditPage的加载逻辑很清楚读取Deck把答案转成页面可编辑的EditableAnswer再用originalSig保存打开时的文本快照。interfaceEditableAnswer{key:string;text:string;}privateasyncload():Promisevoid{if(!this.deckId){return;}this.loadingtrue;try{constdeck:Deck|nullawaitDeckService.get(this.deckId);if(!deck){promptAction.showToast({message:题库不存在});this.pathStack.pop();return;}this.deckNamedeck.name;this.originalNamedeck.name;this.builtIndeck.builtIn;this.answersdeck.answers.map((a:Answer):EditableAnswer{conste:EditableAnswer{key:a.id,text:a.text};returne;});this.originalSigthis.signature();}finally{this.loadingfalse;}}这段代码已经解决了“页面有没有改过”的问题但它只比较当前窗口自己的前后状态。另一个窗口有没有把同一副牌改成新版本页面本身并不知道。保存入口当前是一次性提交没有版本闸门继续看保存入口。现在页面把deckId、deckName、answers组装成SaveDeckPayload直接交给DeckService.save。privateasynconSave():Promisevoid{if(this.saving){return;}if(this.builtIn){promptAction.showToast({message:内置题库不可修改});return;}this.savingtrue;try{constpayload:SaveDeckPayload{id:this.deckId,name:this.deckName,answers:this.answers.map((a:EditableAnswer):stringa.text)};awaitDeckService.save(payload);promptAction.showToast({message:已保存});this.originalSigthis.signature();this.originalNamethis.deckName;this.editingfalse;this.pathStack.pop();}finally{this.savingfalse;}}这个实现适合单窗口编辑也适合用户自己连续修改同一个页面。但在两个窗口同时打开同一副牌时它缺少一个输入这次提交基于哪一个updatedAt。覆盖是怎么发生的多窗口覆盖不是“保存按钮点太快”这么简单它通常按下面的顺序出现。时间点A 窗口B 窗口结果T1打开牌组读取updatedAt100打开同一牌组读取updatedAt100两份草稿都看起来合法T2修改答案 1仍停留旧内容A 有新草稿T3保存成功牌组变成updatedAt120还不知道版本变化仓储已有新版T4已退出编辑页保存旧草稿如果没有版本比较A 的修改被覆盖所以保存前不能只问“当前页面是否 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();}这两个字段的职责要分开字段用在哪里不做什么draftSessionId日志、冲突提示、定位用户哪次编辑不作为牌组主键baseUpdatedAt保存前和仓储最新版本比较不参与排序originalSignature判断当前窗口是否有修改不判断其他窗口变化dirty控制保存按钮和离开确认不代表可以覆盖保存加载时记录基线版本页面加载成功后除了当前已经写入的originalSig还应该记录deck.updatedAt。这一步必须发生在DeckService.get返回之后不能提前用当前时间代替。StateprivatedraftSessionId:string;StateprivatebaseUpdatedAt:number0;StateprivateconflictMessage:string;privateapplyLoadedDeck(deck:Deck):void{this.deckNamedeck.name;this.originalNamedeck.name;this.builtIndeck.builtIn;this.answersdeck.answers.map((a:Answer):EditableAnswer{constitem:EditableAnswer{key:a.id,text:a.text};returnitem;});this.originalSigthis.signature();this.baseUpdatedAtdeck.updatedAt;this.draftSessionIdcreateDraftSessionId(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):PromiseVersionedSaveResult{if(payload.id){constlatest:Deck|nullawaitDeckRepository.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:DeckSummaryawaitthis.save(payload);return{ok:true,summary};}这段代码的关键点是“失败不写入”。一旦发现latest.updatedAt已经变了直接返回冲突结果不尝试自动合并答案列表。对于答案列表这种有顺序、有删除、有长度上限的数据自动合并很容易制造第二个问题。页面冲突处理提示刷新不偷偷覆盖页面保存时只需要补齐两个字段然后根据结果分支展示反馈。冲突时不要调用pathStack.pop()否则用户会以为保存成功。privateasynconSave():Promisevoid{if(!this.canSave()){return;}this.savingtrue;try{constpayload:VersionedSaveDeckPayload{id:this.deckId,name:this.deckName,answers:this.answers.map((a:EditableAnswer):stringa.text),baseUpdatedAt:this.baseUpdatedAt,draftSessionId:this.draftSessionId};constresult:VersionedSaveResultawaitDeckService.saveWithVersion(payload);if(!result.okresult.conflict){this.conflictMessage这副题库已在其他窗口更新请刷新后再保存;return;}promptAction.showToast({message:已保存});this.originalSigthis.signature();this.editingfalse;this.pathStack.pop();}finally{this.savingfalse;}}冲突提示不要只写“保存失败”。用户需要知道下一步是什么刷新、放弃本地草稿、或者另存为新牌组。第一版可以先只做刷新和放弃后续再补另存。刷新冲突重新加载前先保护用户输入发生冲突后直接覆盖页面输入会让用户更困惑。更稳的处理是保留当前草稿同时提供一个显式刷新入口。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)}}这个入口的目标不是做复杂合并而是避免静默丢数据。用户至少能看见“我现在编辑的是旧版本”再决定是否刷新。验证路径要验证成功也要验证拒绝写入只验证单窗口保存是不够的。这个改动真正要证明的是旧草稿不会覆盖新版本。场景操作期望结果单窗口修改保存打开自建牌组改名或改答案后保存保存成功LastDeckUpdateAt更新两窗口同牌组A、B 同时打开A 保存后 B 再保存B 得到冲突提示仓储仍是 A 的结果内置牌组打开默认牌组尝试编辑无法进入保存路径删除后保存编辑页打开后列表页删除该牌组保存时提示牌组不存在不写新数据冲突后刷新B 点击刷新最新版本页面重新加载最新updatedAt和答案本地可以先用rg把落点查清楚Write-Host查看编辑页现有保存链路rg-noriginalSig|baseUpdatedAt|draftSessionId|onSave|DeckService.saveD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\pages\DeckEditPage.etsWrite-Host查看服务层是否已有版本比较rg-nupdatedAt|saveWithVersion|LastDeckUpdateAt|save\\(D:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\services\DeckService.ets这些命令只能确认源码落点。多窗口覆盖需要在模拟器、真机或 DevEco 多实例场景里走完整交互不能只看 Markdown 或静态脚本结论。常见问题现象常见原因处理方式B 窗口保存后覆盖 A 的修改保存时没有比较baseUpdatedAt在DeckService增加版本闸门冲突后页面直接返回冲突结果被当成保存成功处理result.okfalse时留在当前页刷新后仍显示旧答案load()没重新读取仓储或baseUpdatedAt没更新刷新成功后同步originalSig和baseUpdatedAt保存按钮状态不准isDirty()只看文本没结合saving、builtIn、合法答案数量继续让canSave()统一控制入口版本比较总是冲突保存成功后页面仍保留旧baseUpdatedAt成功保存后用返回的summary.updatedAt或重新加载收口第 72 篇的核心不是“加一个草稿对象”而是把编辑页的提交链路补完整打开时记录基线版本保存时由服务层比较最新版本冲突时页面给用户明确选择。这样多窗口、分屏和后台返回都不会把旧草稿静默写回仓储。这篇里的saveWithVersion属于建议补强不是当前工程已经存在的方法。当前工程已经具备updatedAt、originalSig和DeckService.save这些基础只要把版本闸门放对位置就能避免旧窗口覆盖新内容。