HarmonyOS7 页面参数校验要放入口处：ArkUI/ArkTS 实战拆解-CSDN博客

为文章《HarmonyOS7 页面参数校验要放入口处：ArkUI/ArkTS 实战拆解》绘制一张手绘

文章目录

前言

详情页崩溃，很多时候不是接口慢，也不是组件复杂，而是入口参数一开始就是脏的。比如 id 为空、类型不对、从通知跳进来少了字段、老版本页面还传着旧参数。参数校验如果散落在加载数据、渲染标题、点击按钮里，后面排查会很累。

我在 HarmonyOS7 项目里更倾向于把参数校验放在页面入口：进入页面先得到一个可信的 ViewState，后面的 UI 只关心正常态、错误态和加载态。

不要让页面里的每个角落都猜“参数是不是有效”。入口校验一次，后面少很多防御式代码。

为什么这个问题经常被写乱

页面参数校验要放入口处这类内容很容易被写成“代码能跑就算讲完了”，但对初学者来说，这恰恰是最不够的地方。真正让人卡住的，往往不是某个组件名记不住，而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。

所以这篇文章不只想给你一个能跑的例子，更想把背后的判断过程讲清楚。你只要把这个判断过程吃透，后面自己改页面、补需求、查问题时，心里会稳很多。

参数校验要校什么

参数	校验点	失败后的处理
`articleId`	非空、格式正确	展示参数错误页

为文章《HarmonyOS7 页面参数校验要放入口处：ArkUI/ArkTS 实战拆解》绘制一张手绘

我不建议把所有参数都强行校验到很严格。真正会影响数据请求、权限判断、返回路径的参数必须严格；只影响文案的小参数，可以给默认值。

ArkUI/ArkTS 示例

下面示例模拟文章详情页。它把参数解析、错误态、加载态和正文展示都放在一个闭环里。

import { router } from '@kit.ArkUI'

class DetailParams {
  articleId: string = ''
  source: string = 'list'
  preview: boolean = false
}

type PageStatus = 'checking' | 'ready' | 'invalid'

@Entry
@Component
struct DetailParamCheckPage {
  @State pageStatus: PageStatus = 'checking'
  @State errorText: string = ''
  @State title: string = ''
  @State params: DetailParams = new DetailParams()

  aboutToAppear(): void {
    const parsed = this.parseParams(router.getParams())
    if (parsed.articleId.length === 0) {
      this.pageStatus = 'invalid'
      this.errorText = '缺少文章 ID，无法打开详情页'
      return
    }

    this.params = parsed
    this.title = `文章 ${parsed.articleId}`
    this.pageStatus = 'ready'
  }

  private parseParams(raw: Object | undefined): DetailParams {
    const result = new DetailParams()
    const record = raw as Record<string, Object>
    if (record === undefined || record === null) {
      return result
    }

    const idValue = record['articleId']
    if (typeof idValue === 'string' && idValue.trim().length > 0) {
      result.articleId = idValue.trim()
    }

    const sourceValue = record['source']
    if (sourceValue === 'list' || sourceValue === 'push' || sourceValue === 'search') {
      result.source = sourceValue
    }

    const previewValue = record['preview']
    if (typeof previewValue === 'boolean') {
      result.preview = previewValue
    }
    return result
  }

  @Builder
  InvalidView() {
    Column({ space: 12 }) {
      Text('页面打不开').fontSize(22).fontWeight(FontWeight.Bold)
      Text(this.errorText).fontSize(14).fontColor('#666666')
      Button('返回上一页').onClick(() => router.back())
    }
    .padding(24)
    .alignItems(HorizontalAlign.Start)
  }

  @Builder
  ContentView() {
    Column({ space: 12 }) {
      Text(this.title).fontSize(24).fontWeight(FontWeight.Bold)
      Text(`来源：${this.params.source}`).fontSize(13).fontColor('#777777')
      if (this.params.preview) {
        Text('预览模式：部分操作已禁用')
          .fontSize(13)
          .fontColor('#B26B00')
          .padding(10)
          .backgroundColor('#FFF4D8')
          .borderRadius(8)
      }
      Text('这里展示详情内容。实际项目里可以在参数校验通过后再发起网络请求。')
        .fontSize(16)
        .lineHeight(24)
    }
    .padding(16)
    .alignItems(HorizontalAlign.Start)
  }

  build() {
    Column() {
      if (this.pageStatus === 'invalid') {
        this.InvalidView()
      } else if (this.pageStatus === 'ready') {
        this.ContentView()
      } else {
        LoadingProgress().width(36).height(36)
      }
    }
    .width('100%')
    .height('100%')
  }
}

关键代码说明

parseParams() 是整篇的重点。它把不可信的 router.getParams() 转成可信的 DetailParams。后面的 UI 不再直接读取原始参数，避免到处写 typeof 判断。

pageStatus 把页面状态收敛成三个值：检查中、可展示、参数错误。真实项目里可以再加 loading 和 networkError，但不要把“参数错误”和“接口失败”混在一起。

错误态页面 不只是给用户看的，也是给开发者排查问题看的。文案明确到“缺少文章 ID”，比空白页有价值很多。

参数失败时怎么分级

入口校验不是所有失败都直接返回上一页。我会按影响范围分三层处理：

失败类型	例子	UI 策略
必填缺失	`articleId` 为空	错误态，停止请求
可选异常	`source` 不在枚举里	使用默认值并继续
影响权限	`preview`、`fromPush` 异常	降级到保守权限

这种分级能避免页面过度敏感。用户从旧通知、分享链接、搜索结果进入时，参数形态可能并不完全一致，真正要拦截的是会导致错误数据或越权操作的字段。

参数错误后不要继续硬跑

参数校验失败后，最重要的是停住后续链路。缺少 articleId 时继续请求接口，只会把一个入口问题伪装成网络问题，排查方向会被带偏。

可选参数可以更宽松。source 不在预期范围内时，使用默认来源继续展示，比直接把页面打断更合适。真正需要拦截的是会影响数据请求、权限判断和返回路径的字段。

UI 也不要再读取原始 params。入口处解析出 DetailParams 后，页面后续只面对可信对象和 pageStatus，这样代码会少很多重复判断。

写在最后

参数校验看起来是小事，但它决定了页面的下限。HarmonyOS7 页面越多、入口越复杂，就越应该把这件事前置。入口处多写十几行清晰代码，后面能少掉很多隐形 bug。