问题是怎么露出来的中式美食首页有一组菜谱卡片卡片里有封面、菜名、评分、收藏按钮和跳转详情。最早我把卡片拆成Builder是为了让列表页看起来干净一点列表只负责循环卡片负责展示。这个方向没问题问题出在参数边界没有拆清楚。页面刷新、筛选、排序以后卡片显示的是新数据但是点击事件里拿到的还是旧对象。表现出来就是几种很烦人的问题操作表现搜索后点第一张卡片详情页偶尔打开搜索前的菜谱点收藏按钮UI 上变的是当前卡片写入时却可能写到旧 recipeId切换分类再返回卡片顺序变了事件回调还按旧下标理解快速连续点击页面跳转和收藏状态偶尔对不上这种问题不一定每次复现所以更容易被忽略。它不是 ArkUI 不能用也不是Builder有问题而是我把“展示数据”和“业务身份”混在一起传了。当时的写法哪里不稳先看一段容易出问题的写法。为了省事卡片拿到的是整个recipe对象事件里也直接用这个对象。为什么这个写法在中式美食里容易出问题原因很简单菜谱列表不是一组固定不动的静态数据。搜索会换结果分类会换结果收藏会局部改状态推荐排序还会把同一批菜重新排一遍。这个时候如果事件回调依赖旧对象或者旧下标坏处就是排查时看不到明显报错但业务身份已经悄悄错了。用户看到的是当前卡片代码处理的却可能是刷新前那一道菜。BuilderfunctionRecipeCard(recipe:RecipeItem){Column(){Image(recipe.cover).width(100%).height(128)Text(recipe.name).fontSize(16).fontWeight(FontWeight.Medium)Row(){Text(recipe.score.toFixed(1))Button(recipe.favorite?已收藏:收藏).onClick((){this.toggleFavorite(recipe)})}}.onClick((){this.openRecipeDetail(recipe)})}这段代码在静态列表里看不出问题。真正麻烦的是列表会变搜索会过滤分类会切换排序会重排收藏后还会局部刷新。recipe是一个对象闭包里抓到的对象不一定还能代表当前这张卡片。再加上如果列表里用了不稳定的 key比如直接用 indexLazyForEach(this.recipeDataSource,(item:RecipeItem,index:number){RecipeCard(item)},(item:RecipeItem,index:number)${index})列表一重排index 还是 0、1、2但是 0 位置上的菜已经不是刚才那道菜了。UI 复用了事件闭包也容易跟着混乱。最后看到的现象就是“点 A处理到 B”。我先把卡片参数分成两类后面我没有继续在卡片里补判断而是先把参数重新分了一下。卡片真正需要的东西其实分成两类参数类型例子处理方式展示参数菜名、封面、评分、收藏状态可以作为只读数据传给卡片业务身份recipeId必须稳定所有事件只传它事件回调点击、收藏、加入购物清单只往父组件抛事件不在卡片里改仓库列表 keyrecipeId不能用 index这样拆完以后Builder就不再拿整个对象去做业务判断。它只负责把当前数据显示出来然后把稳定的recipeId往外传。改完后的 Builder 写法我现在会给卡片定义一个更窄的参数结构。它可以包含展示字段但事件里只使用recipeId。typeRecipeCardView{recipeId:stringname:stringcover:stringscore:numberfavorite:booleancookingMinutes:number}typeRecipeCardAction{onOpen:(recipeId:string)voidonFavorite:(recipeId:string)voidonAddToShoppingList:(recipeId:string)void}卡片本身只做展示和事件转发BuilderfunctionRecipeCardViewBuilder(item:RecipeCardView,action:RecipeCardAction){Column(){Image(item.cover).width(100%).height(128).objectFit(ImageFit.Cover)Text(item.name).fontSize(16).fontWeight(FontWeight.Medium).maxLines(1).textOverflow({overflow:TextOverflow.Ellipsis})Row(){Text(${item.score.toFixed(1)}分).fontSize(12)Blank()Button(item.favorite?已收藏:收藏).onClick((event:ClickEvent){event.stopPropagation()action.onFavorite(item.recipeId)})}Button(加入购物清单).onClick((event:ClickEvent){event.stopPropagation()action.onAddToShoppingList(item.recipeId)})}.onClick((){action.onOpen(item.recipeId)})}这里有两个点很关键。第一卡片不直接调用仓库也不直接改recipe.favorite。它只说“哪个 recipeId 被点了”。真正要不要收藏、怎么写 Preferences、要不要同步 RDB都在父组件或 repository 里处理。第二按钮内部用了event.stopPropagation()。不然点收藏时外层卡片的onClick也会触发用户本来只是收藏结果页面还跳到详情。这个问题在移动端很常见尤其卡片里按钮很多的时候。LazyForEach 的 key 必须跟业务身份一致卡片参数改了以后列表 key 也要一起改。如果这里还用 index前面的改动只能解决一半。LazyForEach(this.recipeDataSource,(item:RecipeCardView){RecipeCardViewBuilder(item,{onOpen:(recipeId:string)this.openRecipeDetail(recipeId),onFavorite:(recipeId:string)this.toggleFavorite(recipeId),onAddToShoppingList:(recipeId:string)this.addToShoppingList(recipeId)})},(item:RecipeCardView)item.recipeId)recipeId是菜谱身份搜索、筛选、排序以后也不会变。这样 ArkUI 复用列表项时能知道哪一项才是同一项不会只按位置去理解。中式美食这里尤其要注意因为首页推荐、分类页、搜索结果页都可能复用同一张菜谱卡片。如果每个页面都自己随手写一个 key后面排查会很痛苦。父组件统一处理业务动作父组件拿到recipeId后再去仓库里取最新数据。这样即使列表刚刷新过事件处理也不会依赖闭包里的旧对象。privateopenRecipeDetail(recipeId:string):void{constrecipethis.recipeRepository.findById(recipeId)if(!recipe){promptAction.showToast({message:这道菜刚刚更新了请重新打开})return}this.navPathStack.pushPath({name:RecipeDetailPage,param:{recipeId}})}收藏也是同样的思路privateasynctoggleFavorite(recipeId:string):Promisevoid{constcurrentthis.recipeRepository.findById(recipeId)if(!current){return}constnextFavorite!current.favoriteawaitthis.favoriteRepository.setFavorite(recipeId,nextFavorite)this.recipeDataSource.updateOne(recipeId,{favorite:nextFavorite})}这里我不让卡片自己决定收藏状态怎么落库。卡片只负责触发动作父组件负责拿最新数据repository 负责写入。这样问题发生时也好查是事件传错了还是仓库写错了还是 dataSource 没刷新。DataSource 也不要按下标更新如果toggleFavorite最后还是按 index 更新问题还会回来。所以数据源也要按recipeId找项。classRecipeCardDataSourceimplementsIDataSource{privateitems:RecipeCardView[][]privatelisteners:DataChangeListener[][]updateOne(recipeId:string,patch:PartialRecipeCardView):void{constindexthis.items.findIndex(itemitem.recipeIdrecipeId)if(index0){return}this.items[index]{...this.items[index],...patch}this.listeners.forEach(listener{listener.onDataChange(index)})}totalCount():number{returnthis.items.length}getData(index:number):RecipeCardView{returnthis.items[index]}registerDataChangeListener(listener:DataChangeListener):void{this.listeners.push(listener)}unregisterDataChangeListener(listener:DataChangeListener):void{this.listenersthis.listeners.filter(itemitem!listener)}}这段代码解决的是“知道哪一项变了”的问题。只要业务身份稳定局部刷新就有依据。否则列表一重排按下标更新很容易把状态贴到另一张卡片上。我怎么验证这次没有串线这类问题不能只点一次卡片就算通过。我会按中式美食的真实使用链路测验证动作预期结果首页打开后点第一张卡片详情页 recipeId 和卡片 recipeId 一致搜索“鸡”后点第三张卡片打开的详情必须是搜索结果里的第三道菜收藏搜索结果中的菜谱只改变当前 recipeId 对应的收藏状态切换分类后再点收藏不影响切换前列表里的旧对象加入购物清单后返回卡片点击、收藏、购物清单入口互不串线我还会临时加一段日志只在调试阶段用确认事件传出来的recipeId和当前卡片展示的是同一个。privatedebugCardAction(action:string,recipeId:string):void{constitemthis.recipeRepository.findById(recipeId)console.info([RecipeCard]${action},{recipeId,name:item?.name??missing})}如果日志里出现missing说明事件传出来的身份已经不可靠如果 name 和页面看到的菜名对不上基本就是 key、闭包或者 dataSource 更新顺序出了问题。后面我会怎么避免现在我写中式美食这种卡片组件会先定三条规则。第一Builder里不要直接藏业务逻辑。它可以显示 UI可以把点击事件抛出去但不要自己决定数据怎么写。第二事件参数优先传稳定 ID不传整对象。对象适合展示ID 适合做业务动作。搜索、排序、分页以后旧对象最容易误导人。第三列表 key、事件参数、仓库查询都使用同一个业务身份。中式美食这里就是recipeId。只要这条线统一卡片复用、局部刷新、收藏状态同步都会稳很多。这次问题给我的提醒是ArkUI Builder 拆组件时不要只看代码有没有变短。真正要盯的是边界有没有变清楚。卡片负责展示父组件负责动作repository 负责数据这三层分清以后页面才不容易出现“看着是这道菜点出去是另一道菜”的问题。
