大家好，我是杨利杰 YJlio。

前两节整理了页面跳转与参数传递。这一节回到原稿的 count 示例：先增加数量，再进入详情页，返回后检查数量。通过这个小练习，我想分清“原页面仍在”与“页面重新创建”两种情况。

本篇编号 023，计划日期为 2026 年 10 月 13 日。原稿已保留；下方双页面代码是补充的学习示例，尚未在本机编译或设备运行。配图均为概念示意。

一、返回后，先检查是不是原来的页面状态

本例让首页 Index 持有 count，详情页 Detail 只提供返回按钮。进入详情前记录 count，返回后再次读取首页上的数量。

这次没有修改详情数据，也没有把 count 传给详情页。重点是观察原首页状态，而不是练习页面间回传结果。

二、保留首页的计数逻辑

原稿将 count 初始值设为 0，点击“增加”后加 1。我保留这一点，再添加进入详情的按钮与跳转失败提示。

首页 Index.ets 示例：

import{BusinessError}from'@kit.BasicServicesKit';@Entry@Componentstruct Index{@Statecount:number=0;@Statemessage:string='';aboutToAppear():void{console.info(`Index aboutToAppear count=${this.count}`);}onPageShow():void{console.info(`Index onPageShow count=${this.count}`);}privateopenDetail():void{this.message='';this.getUIContext().getRouter().pushUrl({url:'pages/Detail'},(err:BusinessError)=>{if(err){this.message='跳转失败';console.error(`pushUrl failed:${err.code},${err.message}`);}});}build(){Column({space:12}){Text(`当前数量：${this.count}`)Text(this.message)Button('增加').onClick(()=>{this.count+=1})Button('查看详情').onClick(()=>{this.openDetail()})}.width('100%').padding(16)}}

两处生命周期日志只记录状态，没有给 count 重新赋值。日志文本是观察入口，不是已经获取的运行日志。

三、用 pushUrl 保留首页的页面栈位置

本例仍使用上一节的 pages/Index 与 pages/Detail 两个注册名称。它们对应各自的页面文件，实际配置需核对当前模块的 main_pages.json 等页面清单，不覆盖已有注册内容。

官方 Router 文档说明，pushUrl 会把目标页加入页面栈，同时保留当前页。本例进入详情后，Index 在下面，Detail 在上面。

如果首页没有被销毁、重建或主动清空状态，返回时应检查的是原来这份 count。换成 replaceUrl 会改变页面栈关系，不能继续按同一个保留页面的前提推断。

四、详情页通过 back 返回上一页

详情页 Detail.ets 示例：

@Entry@Componentstruct Detail{build(){Column({space:12}){Text('详情页')Button('返回').onClick(()=>{this.getUIContext().getRouter().back()})}.width('100%').padding(16)}}

Index 和 Detail 分别放在两个页面文件中。这里的返回依赖页面栈中存在上一页；直接启动详情页时，不能假定 back 一定能回到首页。

返回到哪个页面，应根据当前页面栈判断；返回按钮的文字不决定目标。

五、把状态保留与新建页面的初值分开看

在本例的预期路径中，首页 count 增加后通过 pushUrl 暂时不显示，再通过 back 回到原首页，应核对它是否仍保留离开时的数值。

新建一个 Index 实例时，字段声明的 count 初始值仍为 0。两个页面都显示“首页”，并不意味着它们是同一个实例。

页面看起来一样，不代表页面实例和状态来源一样。

六、重新显示，不等于重新创建

onPageShow 用于观察页面显示；aboutToAppear 属于自定义组件生命周期，在新实例创建后的构建阶段执行。两者承担的观察职责不同。

如果在 onPageShow 中每次都把 count 写成 0，返回后也可能被自己的代码重置。这时需要检查赋值位置，不能直接归因于框架没有保存状态。

本例仅记录日志，方便对照进入、返回与新建过程。具体回调顺序和触发次数仍需在自己的工程中观察；不要从一张概念图推断完整生命周期时序。

七、页面保留与跨重启持久化分别处理

@State count 是本例组件中的状态，它没有写入 Preferences、文件或数据库。因此，本篇没有实现跨应用重启的保存与恢复。

如果希望下次启动仍恢复数量，需要明确保存时机、读取时机、默认值及失败处理。后续会分别学习相应存储机制，这节先保持计数与返回路径最小化。

本文继续使用 Router 练习页面栈。官方资料推荐新项目使用 Navigation，迁移时应按对应体系重新核对返回关系与状态归属。

八、沿完整路径记录进入前与返回后

环境记录应包含实际 DevEco Studio、SDK/API、设备与窗口。如果数量变化不符合预期，保存完整日志和操作顺序，列出所有给 count 赋值的位置。

代码采用 V1 的 @Component、@State 和相应 Router 接口，当前工程若使用其他模板应先适配。系列名称不代表任何指定 SDK 的编译验证。

先确认返回目标，再确认页面是否重建，最后追踪状态的所有赋值来源。

写在最后

这节我用 count 把返回问题拆成了三个检查点：页面栈是否保留首页、返回是否回到原实例、数量是否被其他代码覆盖。

标题中的“状态恢复”在本例主要体现为返回后重新看到原状态；跨重启恢复与持久化仍是后续内容。下一篇学习表单输入校验与提交反馈，继续记录输入、操作和可观察结果。

参考资料

1. OpenHarmony 官方文档：页面路由，用于核对 pushUrl、back、页面显示生命周期与 Navigation 推荐说明。
2. OpenHarmony 官方文档：自定义组件生命周期，用于区分组件创建与页面显示；实际 HarmonyOS 工程以对应 SDK 文档为准。
3. 本系列第 023 篇原稿：《返回导航与页面状态恢复》，计划日期 2026-10-13。

声明：本文为个人学习笔记，代码与概念配图用于说明返回路径和状态检查；未执行本机编译或设备实测，日志与预期结果不能当作运行证据。

返回顶部