先说这个问题是怎么冒出来的中式美食的菜谱列表一开始很简单接口里拿一批菜谱页面上铺出来能点进详情就行。后来功能慢慢加多了搜索关键词、分类筛选、收藏状态、评分、最近浏览都要在同一个列表里体现这时候问题就出来了。我遇到的现象不是页面直接报错而是那种更烦人的“小错”筛选一次列表返回后位置偶尔跳到顶部刚收藏的菜换个分类再回来好像收藏态跑到了另一张卡片上有时候数据已经更新了页面却像慢半拍一样。表面看是 LazyForEach 刷新不稳定实际往下查主要还是 key、数据源通知和整表重建这三件事没分清。这篇不讲抽象概念只按中式美食菜谱列表这条线说为什么会乱、怎么拆、怎么验证后面写 HarmonyOS/ArkUI 列表时也能少踩这个坑。环境和页面范围项目说明运行环境HarmonyOS Stage 模型页面范围中式美食菜谱列表、分类筛选、搜索结果、详情返回主要技术ArkUI、ArkTS、LazyForEach、自定义数据源核心状态recipeId、favorite、score、viewedAt、filterKey、sortMode这类问题不适合只看一段 UI 代码。列表页能不能稳定至少要把三层放在一起看页面筛选条件、列表数据源、单个菜谱卡片状态。只改其中一层很容易看起来修好了实际换个操作顺序又复现。一开始为什么会乱我一开始的写法比较直接筛选条件变了以后就重新生成一个数组然后让列表重新渲染。数组本身没错问题是列表项的身份没有稳定下来。typeRecipeItem{recipeId:stringtitle:stringcategory:stringfavorite:booleanscore:numberviewedAt?:number}如果页面只是展示静态列表数组下标看起来也能跑。但中式美食的列表不是静态的用户会搜索“番茄”、切换“家常菜”、点收藏、进详情再回来。只要列表顺序发生变化下标就不再代表同一道菜。// 这个写法最容易埋坑位置变了身份也跟着变了LazyForEach(this.dataSource,(item:RecipeItem,index:number){RecipeCard({recipe:item})},(item:RecipeItem,index:number)index.toString())这个问题的坏处是它不一定每次都出现。数据少的时候、刷新慢的时候、只做一次筛选的时候都可能正常。等功能变多列表项复用频繁卡片里又有收藏、评分、加载图这些状态就开始暴露。key 要跟菜谱身份走不要跟位置走后来我把列表项身份固定到recipeId。这个字段在中式美食里代表一道菜不管它在“家常菜”分类里排第几也不管搜索后排到哪里身份都不变。LazyForEach(this.recipeDataSource,(item:RecipeItem){RecipeCard({recipe:item})},(item:RecipeItem)item.recipeId)这个修改看起来很小但影响很大。ArkUI 在复用节点时至少知道“宫保鸡丁还是宫保鸡丁”“番茄牛腩还是番茄牛腩”。位置变了只是排序结果变了不代表这个卡片的业务身份变了。我现在会把列表 key 当成第一道检查项。只要页面里有收藏态、选择态、展开态、图片加载态就不能随手用 index。index 只能说明它在当前数组里的位置不能说明它是谁。数据源通知也要拆开第二个坑是更新范围太粗。以前收藏一道菜以后我会直接重算整个列表再把新数组塞回去。这样做最省事但列表会认为很多东西都变了滚动位置和局部状态就容易被影响。我的做法是把更新拆成两类操作应该怎么更新为什么收藏一道菜只更新这一个 recipeId不影响列表顺序评分变化只通知对应卡片避免整表重绘搜索关键词变化重算可见列表结果集合确实变了分类切换重算可见列表并决定是否重置滚动用户预期进入新列表数据源里保留一个完整数据池再维护当前可见列表。小状态变化只改池子里的单项同时通知对应位置筛选条件变化才重新计算可见列表。classRecipeListDataSourceimplementsIDataSource{privateallRecipes:RecipeItem[][]privatevisibleRecipes:RecipeItem[][]privatelisteners:DataChangeListener[][]totalCount():number{returnthis.visibleRecipes.length}getData(index:number):RecipeItem{returnthis.visibleRecipes[index]}getKey(index:number):string{returnthis.visibleRecipes[index]?.recipeId??empty-${index}}}这里我更愿意让数据源承担“列表现在看到什么”的责任而不是让页面到处拼数组。页面只关心当前关键词、分类和排序条件数据源负责把它们落成稳定的列表。收藏这种小变化不要整表重建收藏状态是最容易看出问题的。用户点了收藏卡片上的星标马上要变但是这件事不应该导致整个列表重新排队。toggleFavorite(recipeId:string):void{constsourceIndexthis.allRecipes.findIndex(itemitem.recipeIdrecipeId)if(sourceIndex0){return}constoldItemthis.allRecipes[sourceIndex]constnextItem:RecipeItem{...oldItem,favorite:!oldItem.favorite}this.allRecipes[sourceIndex]nextItemconstvisibleIndexthis.visibleRecipes.findIndex(itemitem.recipeIdrecipeId)if(visibleIndex0){this.visibleRecipes[visibleIndex]nextItemthis.notifyDataChange(visibleIndex)}}这样做以后收藏只影响那一张卡片。列表不需要重新计算滚动位置也不需要动。用户看到的结果就是点哪一道菜哪一道菜变化不会突然把页面带到别的位置。什么时候才允许重排列表不是所有刷新都应该局部更新。搜索关键词变了、分类变了、排序方式变了这些操作本来就意味着可见列表要重新组织。applyFilter(condition:RecipeFilter):void{this.visibleRecipesthis.allRecipes.filter(itemmatchKeyword(item,condition.keyword)).filter(itemmatchCategory(item,condition.category)).sort((left,right)sortRecipe(left,right,condition.sortMode))this.notifyDataReload()}这里我会刻意把notifyDataChange和notifyDataReload分开。前者是“某一项变了”后者是“这批列表结果变了”。如果这两个动作混着用后面排查会很痛苦因为你很难判断页面到底是因为数据变了还是因为列表身份被重置了。详情返回为什么也会影响列表中式美食里还有一个常见路径列表页点菜谱进入详情用户在详情里收藏或者浏览返回列表后状态要同步。我一开始容易把返回当成“重新进列表”直接重新查一遍数据。这样当然能拿到最新状态但也会把原来的筛选条件和滚动位置冲掉。后来我改成返回时只带回变化项。typeRecipeDetailResult{recipeId:stringfavorite?:booleanscore?:numberviewedAt?:number}onRecipeDetailBack(result?:RecipeDetailResult):void{if(!result?.recipeId){return}this.recipeDataSource.patchRecipe(result.recipeId,result)}这个写法的好处是列表页不用猜用户在详情里做了什么。详情页只把变化交回来列表页按recipeId更新对应卡片。筛选条件、排序模式、滚动位置都还是原来的。我现在怎么验证这个问题这类列表问题不能只靠“页面打开正常”来判断。我会按一个固定链路测操作预期结果搜索“番茄”只出现命中的菜谱列表 key 仍是 recipeId点收藏第一道菜只有这张卡片星标变化进入详情再返回列表保持原来的关键词和滚动位置切换分类再切回收藏态仍跟着对应菜谱不跟着位置修改排序方式列表可重排但卡片状态不串如果这条链路能稳定跑下来才说明问题真的收住了。只刷新一次页面、只看首屏是查不出这类问题的。以后怎么避免我现在写 ArkUI 列表会先问三个问题。第一这个列表项的业务身份是什么如果答案不是数组下标就不要用 index 当 key。中式美食里菜谱就是recipeId食材就是ingredientKey购物清单项也要有自己的稳定标识。第二这次变化是单项变化还是列表结果变化收藏、评分、浏览次数是单项变化搜索、分类、排序才是列表结果变化。两类变化分开后面维护会轻很多。第三详情页返回到底带回了什么如果只是收藏变了就不要把整个列表重新拉一遍。能用变化项修补就用变化项修补。LazyForEach 本身不是问题它只是把列表身份和更新边界放大了。中式美食这个页面的经验是列表越像真实产品越不能只追求“能刷新”。key 稳不稳定、更新粒度粗不粗、返回链路有没有保留现场这些才决定后面功能叠上来会不会乱。你在 HarmonyOS 里做列表时如果也遇到“刷新后位置跳、状态串、返回后现场丢”的问题可以先不急着怀疑框架先把 key、数据源通知、详情返回这三块拆开看通常问题就能定位到很具体的一行代码。
先说这个问题是怎么冒出来的中式美食的菜谱列表一开始很简单接口里拿一批菜谱页面上铺出来能点进详情就行。后来功能慢慢加多了搜索关键词、分类筛选、收藏状态、评分、最近浏览都要在同一个列表里体现这时候问题就出来了。我遇到的现象不是页面直接报错而是那种更烦人的“小错”筛选一次列表返回后位置偶尔跳到顶部刚收藏的菜换个分类再回来好像收藏态跑到了另一张卡片上有时候数据已经更新了页面却像慢半拍一样。表面看是 LazyForEach 刷新不稳定实际往下查主要还是 key、数据源通知和整表重建这三件事没分清。这篇不讲抽象概念只按中式美食菜谱列表这条线说为什么会乱、怎么拆、怎么验证后面写 HarmonyOS/ArkUI 列表时也能少踩这个坑。环境和页面范围项目说明运行环境HarmonyOS Stage 模型页面范围中式美食菜谱列表、分类筛选、搜索结果、详情返回主要技术ArkUI、ArkTS、LazyForEach、自定义数据源核心状态recipeId、favorite、score、viewedAt、filterKey、sortMode这类问题不适合只看一段 UI 代码。列表页能不能稳定至少要把三层放在一起看页面筛选条件、列表数据源、单个菜谱卡片状态。只改其中一层很容易看起来修好了实际换个操作顺序又复现。一开始为什么会乱我一开始的写法比较直接筛选条件变了以后就重新生成一个数组然后让列表重新渲染。数组本身没错问题是列表项的身份没有稳定下来。typeRecipeItem{recipeId:stringtitle:stringcategory:stringfavorite:booleanscore:numberviewedAt?:number}如果页面只是展示静态列表数组下标看起来也能跑。但中式美食的列表不是静态的用户会搜索“番茄”、切换“家常菜”、点收藏、进详情再回来。只要列表顺序发生变化下标就不再代表同一道菜。// 这个写法最容易埋坑位置变了身份也跟着变了LazyForEach(this.dataSource,(item:RecipeItem,index:number){RecipeCard({recipe:item})},(item:RecipeItem,index:number)index.toString())这个问题的坏处是它不一定每次都出现。数据少的时候、刷新慢的时候、只做一次筛选的时候都可能正常。等功能变多列表项复用频繁卡片里又有收藏、评分、加载图这些状态就开始暴露。key 要跟菜谱身份走不要跟位置走后来我把列表项身份固定到recipeId。这个字段在中式美食里代表一道菜不管它在“家常菜”分类里排第几也不管搜索后排到哪里身份都不变。LazyForEach(this.recipeDataSource,(item:RecipeItem){RecipeCard({recipe:item})},(item:RecipeItem)item.recipeId)这个修改看起来很小但影响很大。ArkUI 在复用节点时至少知道“宫保鸡丁还是宫保鸡丁”“番茄牛腩还是番茄牛腩”。位置变了只是排序结果变了不代表这个卡片的业务身份变了。我现在会把列表 key 当成第一道检查项。只要页面里有收藏态、选择态、展开态、图片加载态就不能随手用 index。index 只能说明它在当前数组里的位置不能说明它是谁。数据源通知也要拆开第二个坑是更新范围太粗。以前收藏一道菜以后我会直接重算整个列表再把新数组塞回去。这样做最省事但列表会认为很多东西都变了滚动位置和局部状态就容易被影响。我的做法是把更新拆成两类操作应该怎么更新为什么收藏一道菜只更新这一个 recipeId不影响列表顺序评分变化只通知对应卡片避免整表重绘搜索关键词变化重算可见列表结果集合确实变了分类切换重算可见列表并决定是否重置滚动用户预期进入新列表数据源里保留一个完整数据池再维护当前可见列表。小状态变化只改池子里的单项同时通知对应位置筛选条件变化才重新计算可见列表。classRecipeListDataSourceimplementsIDataSource{privateallRecipes:RecipeItem[][]privatevisibleRecipes:RecipeItem[][]privatelisteners:DataChangeListener[][]totalCount():number{returnthis.visibleRecipes.length}getData(index:number):RecipeItem{returnthis.visibleRecipes[index]}getKey(index:number):string{returnthis.visibleRecipes[index]?.recipeId??empty-${index}}}这里我更愿意让数据源承担“列表现在看到什么”的责任而不是让页面到处拼数组。页面只关心当前关键词、分类和排序条件数据源负责把它们落成稳定的列表。收藏这种小变化不要整表重建收藏状态是最容易看出问题的。用户点了收藏卡片上的星标马上要变但是这件事不应该导致整个列表重新排队。toggleFavorite(recipeId:string):void{constsourceIndexthis.allRecipes.findIndex(itemitem.recipeIdrecipeId)if(sourceIndex0){return}constoldItemthis.allRecipes[sourceIndex]constnextItem:RecipeItem{...oldItem,favorite:!oldItem.favorite}this.allRecipes[sourceIndex]nextItemconstvisibleIndexthis.visibleRecipes.findIndex(itemitem.recipeIdrecipeId)if(visibleIndex0){this.visibleRecipes[visibleIndex]nextItemthis.notifyDataChange(visibleIndex)}}这样做以后收藏只影响那一张卡片。列表不需要重新计算滚动位置也不需要动。用户看到的结果就是点哪一道菜哪一道菜变化不会突然把页面带到别的位置。什么时候才允许重排列表不是所有刷新都应该局部更新。搜索关键词变了、分类变了、排序方式变了这些操作本来就意味着可见列表要重新组织。applyFilter(condition:RecipeFilter):void{this.visibleRecipesthis.allRecipes.filter(itemmatchKeyword(item,condition.keyword)).filter(itemmatchCategory(item,condition.category)).sort((left,right)sortRecipe(left,right,condition.sortMode))this.notifyDataReload()}这里我会刻意把notifyDataChange和notifyDataReload分开。前者是“某一项变了”后者是“这批列表结果变了”。如果这两个动作混着用后面排查会很痛苦因为你很难判断页面到底是因为数据变了还是因为列表身份被重置了。详情返回为什么也会影响列表中式美食里还有一个常见路径列表页点菜谱进入详情用户在详情里收藏或者浏览返回列表后状态要同步。我一开始容易把返回当成“重新进列表”直接重新查一遍数据。这样当然能拿到最新状态但也会把原来的筛选条件和滚动位置冲掉。后来我改成返回时只带回变化项。typeRecipeDetailResult{recipeId:stringfavorite?:booleanscore?:numberviewedAt?:number}onRecipeDetailBack(result?:RecipeDetailResult):void{if(!result?.recipeId){return}this.recipeDataSource.patchRecipe(result.recipeId,result)}这个写法的好处是列表页不用猜用户在详情里做了什么。详情页只把变化交回来列表页按recipeId更新对应卡片。筛选条件、排序模式、滚动位置都还是原来的。我现在怎么验证这个问题这类列表问题不能只靠“页面打开正常”来判断。我会按一个固定链路测操作预期结果搜索“番茄”只出现命中的菜谱列表 key 仍是 recipeId点收藏第一道菜只有这张卡片星标变化进入详情再返回列表保持原来的关键词和滚动位置切换分类再切回收藏态仍跟着对应菜谱不跟着位置修改排序方式列表可重排但卡片状态不串如果这条链路能稳定跑下来才说明问题真的收住了。只刷新一次页面、只看首屏是查不出这类问题的。以后怎么避免我现在写 ArkUI 列表会先问三个问题。第一这个列表项的业务身份是什么如果答案不是数组下标就不要用 index 当 key。中式美食里菜谱就是recipeId食材就是ingredientKey购物清单项也要有自己的稳定标识。第二这次变化是单项变化还是列表结果变化收藏、评分、浏览次数是单项变化搜索、分类、排序才是列表结果变化。两类变化分开后面维护会轻很多。第三详情页返回到底带回了什么如果只是收藏变了就不要把整个列表重新拉一遍。能用变化项修补就用变化项修补。LazyForEach 本身不是问题它只是把列表身份和更新边界放大了。中式美食这个页面的经验是列表越像真实产品越不能只追求“能刷新”。key 稳不稳定、更新粒度粗不粗、返回链路有没有保留现场这些才决定后面功能叠上来会不会乱。你在 HarmonyOS 里做列表时如果也遇到“刷新后位置跳、状态串、返回后现场丢”的问题可以先不急着怀疑框架先把 key、数据源通知、详情返回这三块拆开看通常问题就能定位到很具体的一行代码。
