中式美食从菜谱列表点进详情页看起来只是一个跳转但这里很容易埋坑。有人会把整道菜对象直接放进 NavPathStack 参数详情页拿到对象就展示。刚写时很省事后面一遇到页面恢复、收藏状态变化、菜谱数据更新就会出现参数丢失、字段旧、详情和列表不一致的问题。先看哪里容易错列表页展示的是卡片详情页展示的是完整菜谱。卡片对象通常只够列表用不一定包含完整步骤、营养说明、最近浏览、收藏状态。把这个对象直接传给详情页短期能跑长期会让页面边界变乱。场景传整对象会怎样只传 recipeId 会怎样菜谱字段后来增加详情页拿不到新字段详情页重新读最新数据收藏状态变化对象里的状态可能旧详情页按状态源重新合并页面恢复大对象不稳定小参数更稳列表卡片裁剪字段详情页内容不完整详情页按 id 查完整记录为什么这个问题会反复出现原因是列表页对象和详情页对象职责不同。列表页对象是为了快速展示卡片详情页对象是为了完整展示一条菜谱。把它们混成一份数据后面一定会出现“这里能用、那里不准”的问题。坏写法把整道菜塞进路由下面这种写法很常见点卡片时把recipe整个传进去。openDetail(recipe:RecipeCardVM){this.pathStack.pushPath({name:RecipeDetail,param:{recipe}})}详情页再这样拿aboutToAppear(){constparamthis.pathInfo.paramasRecordstring,RecipeCardVMthis.recipeparam.recipe}这段代码的问题不在于不能跳转而是详情页被列表页的数据结构绑死了。列表卡片为了省首屏性能可能只带标题、封面、评分详情页却需要步骤、食材、收藏、笔记、最近浏览。你把列表对象传过去详情页就只能拿旧对象凑。好写法只传 recipeId更稳的做法是只把recipeId当成路由参数。详情页拿到 id 后自己去 Repository 里读完整数据。openDetail(recipeId:string){this.pathStack.pushPath({name:RecipeDetail,param:{recipeId}})}详情页这样处理Staterecipe:RecipeDetailVM|nullnullStateloading:booleanfalseStateerrorText:stringasyncaboutToAppear(){constparamthis.pathInfo.paramasRecordstring,stringconstrecipeIdparam.recipeIdif(!recipeId){this.errorText菜谱参数不完整return}awaitthis.loadRecipe(recipeId)}privateasyncloadRecipe(recipeId:string){this.loadingtruetry{this.recipeawaitRecipeDetailRepository.instance.getDetail(recipeId)}catch(err){this.errorText菜谱加载失败}finally{this.loadingfalse}}这不是为了多写代码而是为了把责任分清楚。列表页只负责告诉详情页“你要看哪一道菜”详情页自己负责“怎么拿完整数据”。详情页的数据要重新合并状态中式美食详情页不只是菜谱内容还会显示收藏、最近浏览、笔记入口、购物清单入口。这些状态可能在别的页面也会改所以详情页读到菜谱基础信息后还要合并用户状态。classRecipeDetailRepository{asyncgetDetail(recipeId:string):PromiseRecipeDetailVM{constrecipeawaitRecipeDao.findById(recipeId)if(!recipe){thrownewError(recipe not found)}constisFavoriteFavoriteRepository.instance.has(recipeId)constnoteCountawaitNoteRepository.instance.countByRecipeId(recipeId)constviewedAtawaitViewedRepository.instance.touch(recipeId)return{...recipe,isFavorite,noteCount,viewedAt}}}这样做以后详情页不会依赖列表页传来的旧isFavorite。用户从搜索页进、收藏页进、推荐页进详情页都能拿到同一套结果。来源页面传什么详情页怎么处理首页推荐recipeId查完整菜谱并合并收藏搜索结果recipeId查完整菜谱并记录浏览收藏列表recipeId查完整菜谱并确认是否仍收藏最近浏览recipeId查完整菜谱并更新浏览时间参数丢失时要有兜底路由参数再简单也要处理缺失。比如页面被恢复、开发时手动跳转、历史路径不完整都可能让recipeId为空。这个时候不要让详情页白屏。functionreadRecipeId(param:unknown):string{if(!param||typeofparam!object){return}constvalue(paramasRecordstring,string).recipeIdreturntypeofvaluestring?value:}页面层拿不到 id就直接进入错误态constrecipeIdreadRecipeId(this.pathInfo.param)if(!recipeId){this.errorText没有找到这道菜请返回列表重新打开return}这个提示不需要复杂但一定要有。没有兜底时参数一丢用户看到的就是空页面有兜底时至少知道怎么回到列表。不要把缓存当成真实数据还有一种写法看起来折中列表页还是传一份卡片对象详情页先用它展示再慢慢查完整数据。这种写法不是完全不能用但要清楚它只是“临时占位”不能当成真实详情。typeDetailParam{recipeId:stringpreviewTitle?:stringpreviewCover?:string}如果想让详情页打开更快可以传previewTitle和previewCover做首屏占位但真实内容还是要按recipeId重新读。这样用户不会看到空白代码边界也不会乱。asyncaboutToAppear(){constparamthis.pathInfo.paramasDetailParamthis.previewTitleparam.previewTitle||this.previewCoverparam.previewCover||if(!param.recipeId){this.errorText没有找到这道菜请返回列表重新打开return}awaitthis.loadRecipe(param.recipeId)}这里的判断标准很简单占位数据可以旧真实详情不能旧。标题和封面短暂展示一下没问题收藏状态、步骤、笔记数量、购物清单入口必须来自详情页重新读取后的结果。数据可以从参数带吗原因recipeId可以稳定、小、能定位业务对象previewTitle可以只做打开瞬间的占位previewCover可以只做打开瞬间的占位isFavorite不建议可能刚被别的页面改过steps不建议字段大且详情页要最新完整数据这样写还有一个好处后面加预加载、缓存、离线数据时边界不会乱。参数负责“带路”Repository 负责“给最终答案”。怎么验证这个改法验证时不要只从首页点一次详情。要覆盖不同入口。验证动作期待结果能发现的问题首页点菜谱进详情详情完整展示基础跳转是否正常搜索结果进详情能展示完整步骤列表卡片字段是否不够收藏页进详情后取消收藏返回收藏页状态正确收藏状态是否统一最近浏览进详情浏览时间更新详情页是否负责记录浏览手动构造空参数出现错误提示参数兜底是否缺失如果这几条都过了说明详情页不再依赖某个列表对象。入口变多以后页面也不会乱。以后怎么避免以后遇到页面跳转参数先问两个问题。第一这个参数是不是能稳定代表业务对象recipeId可以整道菜对象不一定可以。第二目标页面是不是需要最新数据详情页通常需要所以应该自己读不要相信来源页面顺手带过来的旧对象。解决这类问题的关键不是某个 API而是边界。NavPathStack 负责导航不负责替页面保存完整业务数据Repository 负责拿数据不应该被页面绕开。中式美食的详情页只传recipeId后收藏状态、最近浏览、笔记数量、购物清单入口都可以在详情页统一合并页面恢复和多入口跳转也会稳很多。