NavPathStack 返回错页怎么排查：中式美食详情页从搜索、收藏和推荐进入怎么回到原处

中式美食的菜谱详情页会从很多地方进入：首页推荐、搜索结果、收藏页、购物清单、相关推荐。详情页本身看起来是同一个页面，但返回时不能都按同一种方式处理。从搜索进来，应该回到搜索结果；从收藏进来，应该回到收藏列表；从首页推荐进来，应该回到首页原来的区域。
如果只给详情页传一个 recipeId，页面能打开，但返回路径一定会越来越乱。这个问题不是"返回按钮写错了"这么简单，本质是路由参数没有记录来源。

本文导读

问题	处理方式
详情页不知道从哪里来	route param 里记录 source
返回后搜索词丢失	source 同时带 keyword 和 scrollKey
收藏页返回到首页	根据 source 决定返回策略
连续进详情栈变乱	NavPathStack 操作集中到路由服务

环境和文件边界

项目	内容
开发工具	DevEco Studio
HarmonyOS SDK	API 12，Stage 模型
路由容器	`entry/src/main/ets/router/AppNavStack.ets`
详情页	`entry/src/main/ets/features/recipe/RecipeDetailPage.ets`
搜索页	`entry/src/main/ets/features/search/SearchPage.ets`
收藏页	`entry/src/main/ets/features/favorite/FavoritePage.ets`
本文重点	NavPathStack 来源记录、返回恢复和栈清理

错误写法：只传 recipeId

ts 复制代码

Button('查看详情').onClick(() => {
  this.navStack.pushPath({
    name: 'RecipeDetail',
    param: { recipeId: item.recipeId }
  })
})

这段代码能打开详情页，但它丢了一个关键信息：用户是从哪里来的。详情页只知道要展示哪道菜，不知道返回时应该恢复哪个列表。

把来源放进路由参数

ts 复制代码

export interface RecipeDetailRouteParam {
  recipeId: string
  source: 'home' | 'search' | 'favorite' | 'recommend' | 'shopping'
  keyword?: string
  categoryId?: string
  scrollKey?: string
}

source 不只是给统计用，它直接影响返回逻辑。keyword、categoryId、scrollKey 是为了恢复页面状态。比如用户从搜索"番茄"进入详情，返回时不应该只回搜索页，还要保留"番茄"的结果和滚动位置。

搜索页进入详情的写法

ts 复制代码

this.navStack.pushPath({
  name: 'RecipeDetail',
  param: {
    recipeId: item.recipeId,
    source: 'search',
    keyword: this.viewModel.keyword,
    categoryId: this.viewModel.categoryId,
    scrollKey: item.recipeId
  } as RecipeDetailRouteParam
})

这里带 scrollKey 是为了返回后能尽量把列表恢复到用户刚才点开的那一行。真实项目里不一定每次都能精确恢复像素位置，但至少要能回到同一组结果，而不是跳回默认推荐。

详情页不要自己猜返回目标

ts 复制代码

export class DetailReturnService {
  resolve(param: RecipeDetailRouteParam): BackTarget {
    if (param.source === 'search') {
      return { page: 'SearchPage', restore: { keyword: param.keyword, categoryId: param.categoryId, scrollKey: param.scrollKey } }
    }
    if (param.source === 'favorite') {
      return { page: 'FavoritePage', restore: { scrollKey: param.scrollKey } }
    }
    if (param.source === 'shopping') {
      return { page: 'ShoppingListPage', restore: { scrollKey: param.scrollKey } }
    }
    return { page: 'HomePage', restore: { section: param.source } }
  }
}

这个服务的价值是把返回规则集中起来。否则每个页面都自己写一段返回逻辑，最后一定会有入口漏掉。

NavPathStack 操作要集中

ts 复制代码

export class AppRouter {
  constructor(private navStack: NavPathStack) {}

  openRecipeDetail(param: RecipeDetailRouteParam): void {
    this.navStack.pushPath({ name: 'RecipeDetail', param })
  }

  backFromDetail(param: RecipeDetailRouteParam): void {
    const target = this.returnService.resolve(param)
    this.navStack.pop()
    this.restoreStore.save(target)
  }
}

这里不是说所有项目都必须封装成 AppRouter，而是说 NavPathStack 的 push、pop、replace 不能散在每个组件里。中式美食这种入口多的详情页，路由规则越集中，后面越好查。

页面恢复状态

ts 复制代码

export class SearchViewModel {
  async restoreFromRoute(restore: SearchRestoreState): Promise<void> {
    this.keyword = restore.keyword ?? ''
    this.categoryId = restore.categoryId ?? 'all'
    await this.search()
    this.pendingScrollKey = restore.scrollKey ?? ''
  }
}

返回以后先恢复搜索条件，再查结果，再滚动定位。顺序不要反。否则列表还没回来就滚动，定位会失败。

回归验收记录

步骤	操作	预期
1	从搜索"番茄"进入详情	返回后仍在搜索页，关键词不丢
2	从收藏页进入详情	返回收藏列表原位置
3	从首页推荐进入详情	返回首页推荐区，不跳搜索页
4	从购物清单进入详情	返回购物清单，不跳首页
5	连续打开两道菜详情	返回顺序和栈一致
6	详情页刷新失败	返回路径不受影响

排查顺序

顺序	先看什么	为什么先看它
1	route param 是否只有 recipeId	只传 recipeId 基本无法恢复来源
2	source 是否覆盖所有入口	漏一个入口就会返回错页
3	keyword 和 scrollKey 是否带上	返回后列表状态要靠这些恢复
4	pop/replace 是否散在组件里	分散操作会让栈行为越来越难查

边界责任

层级	应该负责什么	不应该负责什么
入口页	传入来源和恢复信息	猜详情页怎么返回
详情页	展示菜谱和触发返回	自己写一套入口判断
AppRouter	统一 pushPath 和返回策略	直接处理业务数据
ViewModel	恢复搜索、收藏、滚动状态	操作 NavPathStack

小结

NavPathStack 返回错页，很多时候不是栈 API 本身的问题，而是路由参数没把来源说清楚。只传 recipeId 能打开详情页，但不足以支撑真实产品里的多入口返回。
中式美食后续入口会越来越多，所以我会把 source、keyword、categoryId、scrollKey 这些恢复信息一开始就设计进去。这样不是为了复杂，而是为了用户点返回时能回到他刚才的位置。