HarmonyOS 应用实战 80最近使用别覆盖当前选择区分 lastUsedDeckId 和 currentDeckId最近使用和当前选择混在一起时用户临时切换牌组会覆盖推荐顺序。这个问题不能只靠页面上补一个提示解决因为真正的断点在libraryHSP/src/main/ets/services/DeckService.ets、状态字段和服务 owner 之间。下面按现有工程事实展开先看源码再说明风险链路最后给出可以落地的补强方式。这篇解决什么最近使用牌组角度结论落点当前事实当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。libraryHSP/src/main/ets/services/DeckService.ets主要风险最近使用和当前选择混在一起时用户临时切换牌组会覆盖推荐顺序。currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。补强方向RecentDeckState完成抽取后再写最近使用不在选择下拉框变化时写入。页面责任最近使用牌组首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。对最近使用牌组来说这张表先把边界固定住当前事实来自libraryHSP/src/main/ets/services/DeckService.ets风险落在currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。补强方案只围绕RecentDeckState展开不把问题扩散成泛泛的 HarmonyOS 状态管理讨论。现有代码锚点最近使用牌组 对应 libraryHSP/src/main/ets/services/DeckService.ets下面这段来自The_Book_of_Answers当前工程锚点是async getCurrentId。它不是装饰性引用而是判断这篇文章能不能落地的依据。0052returnsummaries;0053}00540055asyncget(id:string):PromiseDeck|null{0056returnawaitDeckRepository.loadDeck(id);0057}00580059/** 当前选中的题库 id未设置时返回默认题库 id */0060asyncgetCurrentId():Promisestring{0061constid:stringawaitPreferencesStore.getString(0062PrefStoreName.App,AppPrefKey.CurrentDeckId,DEFAULT_DECK_ID0063);0064returnid||DEFAULT_DECK_ID;0065}00660067asyncsetCurrent(id:string):Promisevoid{0068constdeck:Deck|nullawaitDeckRepository.loadDeck(id);这段代码说明当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。 所以后续补强不能绕开这个事实如果把最近使用牌组直接写成页面局部变量第一次交互可能看起来没问题跨页面、重进或发布回归时就会暴露。失败链路问题通常不是突然出现最近使用和当前选择混在一起时用户临时切换牌组会覆盖推荐顺序。环节内容排查动作触发点选择牌组确认输入来自哪里断点currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。确认服务层有没有拦住外显现象最近使用总是当前项确认页面有没有清楚反馈这张断点表是给最近使用牌组做回归时用的。先复现触发点再检查currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。是否存在最后看用户能不能从最近使用总是当前项这种现象里得到下一步动作。先排除误区最近使用牌组 不是页面补丁遇到最近使用牌组最容易犯的错是先在页面里加一个局部状态让当前场景看起来正常。这个做法短期能遮住现象但不会处理最近使用总是当前项这类断点。临时做法看起来解决了什么后续会留下什么页面里直接改State当前界面刷新了服务和仓储没有真实状态保存失败后直接返回用户看不到报错数据可能没有写入每个入口各写一份判断某个页面正常其他入口继续出错只看成功路径操作流程很顺失败分支无法复现functionunsafeHandleArticle80(reason:string):void{if(!reason){return;}promptAction.showToast({message:reason});// 只提示不收口下一次进入仍可能遇到同一个 最近使用牌组 问题。}这段反例的目的不是讲语法而是提醒边界最近使用牌组的根因要回到完成抽取后再写最近使用不在选择下拉框变化时写入。页面只能表达反馈不能替服务层决定数据是否已经可靠。按照图里的顺序看真正要拦住的是这一句currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。 只要这个点没有收口用户看到的现象就会在刷新、保存、返回、导入或发布时反复变化。责任边界最近使用牌组 不该由谁兜底DeckService 维护当前选择RecentDeckService 维护最近使用首页只读取推荐列表。层级应该负责不应该负责页面首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。直接改底层 key 或吞掉失败服务完成抽取后再写最近使用不在选择下拉框变化时写入。让每个页面复制一套规则仓储/配置只保存和读取真实数据理解页面交互语义排查最近使用牌组时先问 owner再问信号最后才看样式。像最近使用总是当前项通常不是单纯的 UI 细节而是把 currentDeckId 当历史列表没被服务层收住。状态模型RecentDeckState建议把这件事压成一个明确模型。下面代码是建议补强不表示当前工程已经存在同名接口。interfaceRecentDeckState{currentDeckId:string;// 当前抽取使用的牌组lastUsedDeckIds:string[];// 最近完成抽取的牌组顺序maxItems:number;// 首页最多展示数量updatedAt:number;// 最近使用列表更新时间}functioncreateRecentDeckState(input:PartialRecentDeckState):RecentDeckState{return{currentDeckId:input.currentDeckId||,lastUsedDeckIds:Array.isArray(input.lastUsedDeckIds)?input.lastUsedDeckIds:[],maxItems:typeofinput.maxItemsnumber?input.maxItems:0,updatedAt:typeofinput.updatedAtnumber?input.updatedAt:0,};}RecentDeckState至少要能回答三个问题输入从哪里来、失败怎么表达、成功之后谁刷新。字段少一点没关系但不能让页面靠猜来决定首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。。提交顺序最近使用牌组 要先有提交点把状态模型写出来以后还要约束提交顺序。否则接口名字很好看实际调用仍可能在页面、服务和仓储之间来回绕。页面先收集用户动作只生成RecentDeckState或等价输入。服务读取必要的当前状态执行完成抽取后再写最近使用不在选择下拉框变化时写入。。通过边界后再写仓储、Preferences 或运行时信号。页面根据结果展示成功、失败、刷新或恢复入口。asyncfunctionsubmitArticle80(state:RecentDeckState):Promisevoid{constresult:RecentDeckStateResultawaitcommitRecentDeckState(state);if(!result.ok){RecentDeckStateNotice(result.reason);return;}AppStorage.setOrCreate(article80ChangedAt,result.changedAt);}这个顺序的价值在失败分支。只要最近使用牌组没通过服务闸门就不应该提前写入运行时信号也不应该让页面表现得像已经保存成功。服务闸门先判断能不能提交最近使用牌组的服务层应该先判断边界再执行写入或刷新。下面的写法把reason返回给页面是为了让删除后仍显示旧牌组能被解释而不是只弹一个“失败”。interfaceRecentDeckStateResult{ok:boolean;reason:string;changedAt:number;}functionexplainRecentDeckState(state:RecentDeckState):string{if(!state.currentDeckId){returncurrentDeckId 不能为空;}return;}asyncfunctioncommitRecentDeckState(state:RecentDeckState):PromiseRecentDeckStateResult{constreason:stringexplainRecentDeckState(state);if(reason){return{ok:false,reason,changedAt:Date.now()};}return{ok:true,reason:ready,changedAt:Date.now()};}这里的关键是最近使用牌组不满足边界时不要写仓储也不要悄悄修改运行时状态。先返回原因页面再决定展示刷新、重试、回退还是放弃入口。页面接入提示可以清楚规则不要搬到 UI页面要做的是把用户动作表达清楚。比如首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。这类信息适合放到 UI但真正的校验和写入顺序仍然应该在服务层。BuilderfunctionRecentDeckStateNotice(reason:string){if(reason){Column({space:8}){Text(最近使用牌组).fontSize(16).fontWeight(FontWeight.Medium)Text(reason).fontSize(13).fontColor(AppColor.danger)}.padding(12).border({width:1,color:AppColor.danger}).borderRadius(AppRadius.md)}}这种接入方式对最近使用牌组有一个好处页面可以保持轻量服务仍然是规则 owner。以后再加列表页、设置页、恢复页或发布回归也不用围绕RecentDeckState复制判断条件。结构收口从源码到验证只走一条线最近使用牌组的结构图要能互相对应源码锚点证明当前事实RecentDeckState描述新增边界服务规则决定提交方式验证点证明仅切换下拉框不应改变最近使用列表。没有被吞掉。验证路径成功和失败都要跑序号验证点1仅切换下拉框不应改变最近使用列表。2完成抽取后该牌组移动到最近使用第一位。3删除牌组后最近使用列表要剔除不存在 id。4超过 maxItems 时保留最新几项。Write-Host查看 最近使用牌组 的源码锚点rg-nasync\ getCurrentId|RecentDeckStateD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\services\DeckService.etsWrite-Host查看相关状态字段rg-ncurrentDeckId|lastUsedDeckIds|maxItems|AppStorageKey|AppPrefKey|StorageLink|updatedAtD:\ProgramData\huawei\lesson\The_Book_of_Answers这些命令只能检查最近使用牌组的源码落点和关键字段不代表已经完成真机交互。涉及仅切换下拉框不应改变最近使用列表。这种场景时还需要在 DevEco/设备侧补完整流程验证。负向回归最近使用牌组 要故意跑坏一次只跑成功路径很容易误判。最近使用牌组至少要准备一组负向样本让服务层证明它会拒绝错误输入而不是靠页面刚好没有触发问题。负向样本期望反应说明缺少currentDeckId返回明确原因不写仓储验证主输入不是默认通过触发最近使用总是当前项保留当前页面状态验证失败分支不会静默返回模拟没有清理失效 id页面显示下一步动作验证用户能继续处理重复执行提交结果保持一致验证服务闸门能承受重进asyncfunctionrunNegativeArticle80(state:RecentDeckState):Promisestring{constresult:RecentDeckStateResultawaitcommitRecentDeckState(state);if(result.ok){returnunexpected success;}returnresult.reason;}这组负向样本能把最近使用牌组从“看起来能用”推进到“失败时也能解释”。写文章时把这部分放出来读者才能按自己的工程复现。常见问题先定位断点现象常见原因优先检查最近使用总是当前项把 currentDeckId 当历史列表独立 lastUsedDeckIds删除后仍显示旧牌组没有清理失效 id读取时过滤 DeckService.get 失败项频繁闪动选择时就更新列表只在抽取成功后提交遇到最近使用牌组的异常时不要先改样式。先确认是哪一层没有交接页面是否保留currentDeckId服务是否统一处理规则仓储或配置是否留下旧值运行时信号是否发出。落地顺序先最小闭环再补体验在libraryHSP/src/main/ets/services/DeckService.ets附近确认当前链路避免改错文件。增加RecentDeckState或等价状态模型字段只保留能解释失败的部分。把最近使用牌组的规则放到服务层页面只展示原因和下一步动作。跑成功路径和失败路径特别是仅切换下拉框不应改变最近使用列表。。constregressionForArticle80:string[][仅切换下拉框不应改变最近使用列表。,完成抽取后该牌组移动到最近使用第一位。,删除牌组后最近使用列表要剔除不存在 id。];收口最近使用牌组 的处理方法可以压成一句话DeckService 维护当前选择RecentDeckService 维护最近使用首页只读取推荐列表。 当前工程已经有可依赖的源码基础文章里的新增接口和函数属于建议补强真正落地时优先保持 owner 清楚再补页面反馈。结论内容边界可以直接复用当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。libraryHSP/src/main/ets/services/DeckService.ets建议新增RecentDeckState完成抽取后再写最近使用不在选择下拉框变化时写入。暂不声明真机行为、CSDN 上传、发布结果没有实际执行就不写成已完成真正落地时优先保持 owner 清楚再补页面反馈。结论内容边界可以直接复用当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。libraryHSP/src/main/ets/services/DeckService.ets建议新增RecentDeckState完成抽取后再写最近使用不在选择下拉框变化时写入。暂不声明真机行为、CSDN 上传、发布结果没有实际执行就不写成已完成 HarmonyOS 应用实战 80最近使用别覆盖当前选择区分 lastUsedDeckId 和 currentDeckId最近使用和当前选择混在一起时用户临时切换牌组会覆盖推荐顺序。这个问题不能只靠页面上补一个提示解决因为真正的断点在libraryHSP/src/main/ets/services/DeckService.ets、状态字段和服务 owner 之间。下面按现有工程事实展开先看源码再说明风险链路最后给出可以落地的补强方式。这篇解决什么最近使用牌组角度结论落点当前事实当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。libraryHSP/src/main/ets/services/DeckService.ets主要风险最近使用和当前选择混在一起时用户临时切换牌组会覆盖推荐顺序。currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。补强方向RecentDeckState完成抽取后再写最近使用不在选择下拉框变化时写入。页面责任最近使用牌组首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。对最近使用牌组来说这张表先把边界固定住当前事实来自libraryHSP/src/main/ets/services/DeckService.ets风险落在currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。补强方案只围绕RecentDeckState展开不把问题扩散成泛泛的 HarmonyOS 状态管理讨论。现有代码锚点最近使用牌组 对应 libraryHSP/src/main/ets/services/DeckService.ets下面这段来自The_Book_of_Answers当前工程锚点是async getCurrentId。它不是装饰性引用而是判断这篇文章能不能落地的依据。0052returnsummaries;0053}00540055asyncget(id:string):PromiseDeck|null{0056returnawaitDeckRepository.loadDeck(id);0057}00580059/** 当前选中的题库 id未设置时返回默认题库 id */0060asyncgetCurrentId():Promisestring{0061constid:stringawaitPreferencesStore.getString(0062PrefStoreName.App,AppPrefKey.CurrentDeckId,DEFAULT_DECK_ID0063);0064returnid||DEFAULT_DECK_ID;0065}00660067asyncsetCurrent(id:string):Promisevoid{0068constdeck:Deck|nullawaitDeckRepository.loadDeck(id);这段代码说明当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。 所以后续补强不能绕开这个事实如果把最近使用牌组直接写成页面局部变量第一次交互可能看起来没问题跨页面、重进或发布回归时就会暴露。失败链路问题通常不是突然出现最近使用和当前选择混在一起时用户临时切换牌组会覆盖推荐顺序。环节内容排查动作触发点选择牌组确认输入来自哪里断点currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。确认服务层有没有拦住外显现象最近使用总是当前项确认页面有没有清楚反馈这张断点表是给最近使用牌组做回归时用的。先复现触发点再检查currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。是否存在最后看用户能不能从最近使用总是当前项这种现象里得到下一步动作。先排除误区最近使用牌组 不是页面补丁遇到最近使用牌组最容易犯的错是先在页面里加一个局部状态让当前场景看起来正常。这个做法短期能遮住现象但不会处理最近使用总是当前项这类断点。临时做法看起来解决了什么后续会留下什么页面里直接改State当前界面刷新了服务和仓储没有真实状态保存失败后直接返回用户看不到报错数据可能没有写入每个入口各写一份判断某个页面正常其他入口继续出错只看成功路径操作流程很顺失败分支无法复现functionunsafeHandleArticle80(reason:string):void{if(!reason){return;}promptAction.showToast({message:reason});// 只提示不收口下一次进入仍可能遇到同一个 最近使用牌组 问题。}这段反例的目的不是讲语法而是提醒边界最近使用牌组的根因要回到完成抽取后再写最近使用不在选择下拉框变化时写入。页面只能表达反馈不能替服务层决定数据是否已经可靠。按照图里的顺序看真正要拦住的是这一句currentDeckId 表达本次抽取选择lastUsedDeckIds 表达历史使用顺序两者不能共用一个 key。 只要这个点没有收口用户看到的现象就会在刷新、保存、返回、导入或发布时反复变化。责任边界最近使用牌组 不该由谁兜底DeckService 维护当前选择RecentDeckService 维护最近使用首页只读取推荐列表。层级应该负责不应该负责页面首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。直接改底层 key 或吞掉失败服务完成抽取后再写最近使用不在选择下拉框变化时写入。让每个页面复制一套规则仓储/配置只保存和读取真实数据理解页面交互语义排查最近使用牌组时先问 owner再问信号最后才看样式。像最近使用总是当前项通常不是单纯的 UI 细节而是把 currentDeckId 当历史列表没被服务层收住。状态模型RecentDeckState建议把这件事压成一个明确模型。下面代码是建议补强不表示当前工程已经存在同名接口。interfaceRecentDeckState{currentDeckId:string;// 当前抽取使用的牌组lastUsedDeckIds:string[];// 最近完成抽取的牌组顺序maxItems:number;// 首页最多展示数量updatedAt:number;// 最近使用列表更新时间}functioncreateRecentDeckState(input:PartialRecentDeckState):RecentDeckState{return{currentDeckId:input.currentDeckId||,lastUsedDeckIds:Array.isArray(input.lastUsedDeckIds)?input.lastUsedDeckIds:[],maxItems:typeofinput.maxItemsnumber?input.maxItems:0,updatedAt:typeofinput.updatedAtnumber?input.updatedAt:0,};}RecentDeckState至少要能回答三个问题输入从哪里来、失败怎么表达、成功之后谁刷新。字段少一点没关系但不能让页面靠猜来决定首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。。提交顺序最近使用牌组 要先有提交点把状态模型写出来以后还要约束提交顺序。否则接口名字很好看实际调用仍可能在页面、服务和仓储之间来回绕。页面先收集用户动作只生成RecentDeckState或等价输入。服务读取必要的当前状态执行完成抽取后再写最近使用不在选择下拉框变化时写入。。通过边界后再写仓储、Preferences 或运行时信号。页面根据结果展示成功、失败、刷新或恢复入口。asyncfunctionsubmitArticle80(state:RecentDeckState):Promisevoid{constresult:RecentDeckStateResultawaitcommitRecentDeckState(state);if(!result.ok){RecentDeckStateNotice(result.reason);return;}AppStorage.setOrCreate(article80ChangedAt,result.changedAt);}这个顺序的价值在失败分支。只要最近使用牌组没通过服务闸门就不应该提前写入运行时信号也不应该让页面表现得像已经保存成功。服务闸门先判断能不能提交最近使用牌组的服务层应该先判断边界再执行写入或刷新。下面的写法把reason返回给页面是为了让删除后仍显示旧牌组能被解释而不是只弹一个“失败”。interfaceRecentDeckStateResult{ok:boolean;reason:string;changedAt:number;}functionexplainRecentDeckState(state:RecentDeckState):string{if(!state.currentDeckId){returncurrentDeckId 不能为空;}return;}asyncfunctioncommitRecentDeckState(state:RecentDeckState):PromiseRecentDeckStateResult{constreason:stringexplainRecentDeckState(state);if(reason){return{ok:false,reason,changedAt:Date.now()};}return{ok:true,reason:ready,changedAt:Date.now()};}这里的关键是最近使用牌组不满足边界时不要写仓储也不要悄悄修改运行时状态。先返回原因页面再决定展示刷新、重试、回退还是放弃入口。页面接入提示可以清楚规则不要搬到 UI页面要做的是把用户动作表达清楚。比如首页推荐读取 lastUsedDeckIds再用 DeckService.get 补齐名称。这类信息适合放到 UI但真正的校验和写入顺序仍然应该在服务层。BuilderfunctionRecentDeckStateNotice(reason:string){if(reason){Column({space:8}){Text(最近使用牌组).fontSize(16).fontWeight(FontWeight.Medium)Text(reason).fontSize(13).fontColor(AppColor.danger)}.padding(12).border({width:1,color:AppColor.danger}).borderRadius(AppRadius.md)}}这种接入方式对最近使用牌组有一个好处页面可以保持轻量服务仍然是规则 owner。以后再加列表页、设置页、恢复页或发布回归也不用围绕RecentDeckState复制判断条件。结构收口从源码到验证只走一条线最近使用牌组的结构图要能互相对应源码锚点证明当前事实RecentDeckState描述新增边界服务规则决定提交方式验证点证明仅切换下拉框不应改变最近使用列表。没有被吞掉。验证路径成功和失败都要跑序号验证点1仅切换下拉框不应改变最近使用列表。2完成抽取后该牌组移动到最近使用第一位。3删除牌组后最近使用列表要剔除不存在 id。4超过 maxItems 时保留最新几项。Write-Host查看 最近使用牌组 的源码锚点rg-nasync\ getCurrentId|RecentDeckStateD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\services\DeckService.etsWrite-Host查看相关状态字段rg-ncurrentDeckId|lastUsedDeckIds|maxItems|AppStorageKey|AppPrefKey|StorageLink|updatedAtD:\ProgramData\huawei\lesson\The_Book_of_Answers这些命令只能检查最近使用牌组的源码落点和关键字段不代表已经完成真机交互。涉及仅切换下拉框不应改变最近使用列表。这种场景时还需要在 DevEco/设备侧补完整流程验证。负向回归最近使用牌组 要故意跑坏一次只跑成功路径很容易误判。最近使用牌组至少要准备一组负向样本让服务层证明它会拒绝错误输入而不是靠页面刚好没有触发问题。负向样本期望反应说明缺少currentDeckId返回明确原因不写仓储验证主输入不是默认通过触发最近使用总是当前项保留当前页面状态验证失败分支不会静默返回模拟没有清理失效 id页面显示下一步动作验证用户能继续处理重复执行提交结果保持一致验证服务闸门能承受重进asyncfunctionrunNegativeArticle80(state:RecentDeckState):Promisestring{constresult:RecentDeckStateResultawaitcommitRecentDeckState(state);if(result.ok){returnunexpected success;}returnresult.reason;}这组负向样本能把最近使用牌组从“看起来能用”推进到“失败时也能解释”。写文章时把这部分放出来读者才能按自己的工程复现。常见问题先定位断点现象常见原因优先检查最近使用总是当前项把 currentDeckId 当历史列表独立 lastUsedDeckIds删除后仍显示旧牌组没有清理失效 id读取时过滤 DeckService.get 失败项频繁闪动选择时就更新列表只在抽取成功后提交遇到最近使用牌组的异常时不要先改样式。先确认是哪一层没有交接页面是否保留currentDeckId服务是否统一处理规则仓储或配置是否留下旧值运行时信号是否发出。落地顺序先最小闭环再补体验在libraryHSP/src/main/ets/services/DeckService.ets附近确认当前链路避免改错文件。增加RecentDeckState或等价状态模型字段只保留能解释失败的部分。把最近使用牌组的规则放到服务层页面只展示原因和下一步动作。跑成功路径和失败路径特别是仅切换下拉框不应改变最近使用列表。。constregressionForArticle80:string[][仅切换下拉框不应改变最近使用列表。,完成抽取后该牌组移动到最近使用第一位。,删除牌组后最近使用列表要剔除不存在 id。];收口最近使用牌组 的处理方法可以压成一句话DeckService 维护当前选择RecentDeckService 维护最近使用首页只读取推荐列表。 当前工程已经有可依赖的源码基础文章里的新增接口和函数属于建议补强真正落地时优先保持 owner 清楚再补页面反馈。结论内容边界可以直接复用当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。libraryHSP/src/main/ets/services/DeckService.ets建议新增RecentDeckState完成抽取后再写最近使用不在选择下拉框变化时写入。暂不声明真机行为、CSDN 上传、发布结果没有实际执行就不写成已完成真正落地时优先保持 owner 清楚再补页面反馈。结论内容边界可以直接复用当前实现把 currentDeckId 作为首页选择器和抽取入口的牌组来源。libraryHSP/src/main/ets/services/DeckService.ets建议新增RecentDeckState完成抽取后再写最近使用不在选择下拉框变化时写入。暂不声明真机行为、CSDN 上传、发布结果没有实际执行就不写成已完成 
