大家好，我是杨利杰 YJlio。

上一节已经整理了 Index 到 Detail 的跳转关系。这一节继续使用这两个页面，只增加一个 ticketId 参数，观察“传什么、收到什么、显示什么”是否一致。

本篇编号 022，计划日期为 2026 年 10 月 12 日。原稿已保留。T-001 是补充学习示例中的虚构 ID，不是真实工单；代码尚未在本机编译或设备运行。配图均为概念示意。

一、先约定一个参数：ticketId

本例只传一个 string 类型的 ticketId，示例值为 T-001。字段名、类型与用途先约定清楚，避免发送方写 id，接收方却读取 ticketId。

这里传的是标识，不是完整工单对象。这样可以先核对路由参数关系，再考虑按 ID 查询详情的业务过程。

二、目标路径与业务参数分别填写

url 决定跳转到哪个页面，params 描述带给目标页的参数。两者不能混为一条路径。

本例仍使用 pages/Detail，Index.ets 和 Detail.ets 仍需按上一节在页面配置中注册。以下为首页 Index.ets 的学习示例：

import{BusinessError}from'@kit.BasicServicesKit';@Entry@Componentstruct Index{@Statemessage:string='';privateopenDetail():void{this.message='';this.getUIContext().getRouter().pushUrl({url:'pages/Detail',params:{ticketId:'T-001'}},(err:BusinessError)=>{if(err){this.message='跳转失败';console.error(`pushUrl failed:${err.code},${err.message}`);}});}build(){Column({space:12}){Text('首页')Text(this.message)Button('查看详情').onClick(()=>{this.openDetail()})}.width('100%').padding(16)}}

这里不把 ticketId 拼进 URL，也不预设网络接口。若目标页面没有正确注册，参数填写正确也不能代替页面配置。

三、在详情页读取传入参数

官方 Router 接口提供 getParams 获取当前页的路由参数。本例在 Detail 的 aboutToAppear 中读取，再写入用于显示的状态字段。

Detail.ets 中的完整学习示例如下：

interfaceTicketRouteParams{ticketId?:string;}@Entry@Componentstruct Detail{@StateticketId:string='';@StateerrorMessage:string='';aboutToAppear():void{this.ticketId='';this.errorMessage='';constparams=this.getUIContext().getRouter().getParams()asTicketRouteParams|undefined;if(params&&typeofparams.ticketId==='string'&&params.ticketId.trim().length>0){this.ticketId=params.ticketId.trim();}else{this.errorMessage='缺少有效工单ID';}}build(){Column({space:12}){Text('详情页')if(this.errorMessage.length>0){Text(this.errorMessage)}else{Text(`工单ID：${this.ticketId}`)}Button('返回').onClick(()=>{this.getUIContext().getRouter().back()})}.width('100%').padding(16)}}

首页和详情页代码分别放在自己的页面文件中。这里使用 V1 状态管理及对应 Router 接口；实际工程需核对 SDK 与模板，不能把系列名称当作版本实测证据。

四、类型声明与运行时检查都要看

TicketRouteParams 的字段定义方便说明参数约定，但 as 类型断言不会自动验证传入内容。

本例依次检查参数是否存在、ticketId 是否为 string，以及去掉首尾空格后是否非空。只有通过这些条件，才把规范化后的值写入 ticketId。

类型断言帮助表达预期类型，不能代替实际参数校验。

这组检查只证明字符串具备本例要求的基本形式，并不证明该工单存在，也不证明它属于当前用户。真实业务还需由详情查询和对应业务规则确认。

五、显示校验后的 ID，先核对传递关系

按示例逻辑，传入 T-001 后应显示“工单ID：T-001”。正文与配图中的 ID、字段名和文案均使用同一组值。

这个页面还没有工单标题、状态或处理记录。因此，“显示详情”在本节具体指参数 ID 的展示，不能称为已加载完整业务详情。

如果显示为空或不一致，我会先核对发送对象、读取字段和状态赋值，再检查页面显示绑定点。

六、缺参和空值都给出明确反馈

如果没有传入 ticketId，或者它不是有效的非空字符串，本例显示“缺少有效工单ID”。这与首页跳转失败的提示不同：一个是进入详情后的参数问题，一个是路由调用失败。

本例不会悄悄补一个默认 T-001，让缺参页面看起来像正常详情。否则排查时很容易把默认值误当作实际收到的 ID。

缺少有效参数时，应显示明确反馈，不能用默认业务 ID 掩盖问题。

返回按钮仍然保留，实际返回目标要结合页面栈核对。直接打开详情页与从首页进入，是两种需要分别观察的入口。

七、ID 传递与详情加载是两个步骤

本例只完成参数读取与展示的学习代码，没有网络请求、数据库查询或真实工单详情。

以后接入查询时，可以先确认有效 ID，再按查询结果切换加载、错误、空态和内容显示。路由参数有效，不代表业务数据一定存在；查询返回的数据也需要与请求的 ID 对应。

本文继续采用 Router 练习。官方资料推荐新项目使用 Navigation，两套体系应按各自规则实现参数与导航，不能直接把这段代码当作 Navigation 示例。

八、把正常与异常输入分别记录

测试不同输入时，应在独立练习工程中记录实际改动，不覆盖正式业务数据。环境栏补充真实 DevEco Studio、SDK/API、设备与窗口，保存报错和复现步骤。

预期结果指导验证；传递、校验和显示都要保留真实运行记录。

写在最后

这节我把参数关系拆成四个位置：发送方约定 ticketId，路由携带参数，详情页读取并校验，最后显示规范化后的值。

下一篇继续学习返回导航与页面状态恢复，在这两个页面的基础上检查返回后哪些信息仍在、哪些需要重新读取。

参考资料

1. OpenHarmony 官方接口文档：UIContext Router，用于核对 pushUrl、params、getParams 和 back；实际 HarmonyOS 工程以对应 SDK 文档为准。
2. OpenHarmony 官方文档：页面路由，用于核对基础路由与 Navigation 推荐说明。
3. 本系列第 022 篇原稿：《页面参数传递与详情展示》，计划日期 2026-10-12。

声明：本文为个人学习笔记，T-001 为虚构演示 ID，代码与概念图不代表真实工单或设备实测；实际行为需结合工程环境验证。

返回顶部