HarmonyOS7 aboutToDisappear 别乱改状态：ArkUI/ArkTS 实战拆解

前言

aboutToDisappear 很容易被误用。很多人觉得组件要销毁了，正好把 @State 改一改、把表单保存一下、把页面状态复原一下。这个思路在 HarmonyOS7 的 ArkUI 里风险很高，因为组件已经进入销毁流程，此时修改状态不仅没有必要，还可能引发不稳定的刷新和难查的问题。

我更愿意把 aboutToDisappear 当成“清理现场”的地方：停定时器、取消监听、释放资源。至于表单保存、返回确认、草稿提示，应该发生在用户动作或页面级返回处理里，而不是组件临走前再补一刀。

一句话原则：aboutToDisappear 可以清资源，不要改 UI 状态；要不要离开页面，交给 onBackPress 或明确按钮事件处理。

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

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

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

场景：编辑页离开前处理草稿

假设我们有一个备注编辑页，用户可以输入内容。需求是：

• 用户输入后显示“未保存”状态
• 点击保存后更新提示
• 返回时如果有未保存内容，先拦截返回

• 组件销毁时只清理计时器，不再修改 @State

状态处理策略

这个策略还有一个好处：离开页面这件事变得可预测。用户点保存、点清空、按返回键，每个动作都能在发生时给反馈；组件真正销毁时，只做不会影响界面的清理动作。

先把页面目标想清楚

在真正写代码之前，先别急着盯着 API。更有用的做法是先想清楚：这个页面到底想解决什么问题，用户最在意的反馈是什么，哪些状态必须一直保持一致。

当你先把这条主线想明白，再回头看组件和状态设计，很多选择都会顺理成章。对小白来说，这一步尤其重要，因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。

完整代码示例

@Entry
@Component
struct EditDisappearPage {
  @State content: string = ''
  @State savedContent: string = ''
  @State notice: string = '可以开始记录今天的处理意见'
  private autoSaveTimer: number = -1

  aboutToAppear(): void {
    this.autoSaveTimer = setInterval(() => {
      if (this.content.length > 0 && this.content !== this.savedContent) {
        this.savedContent = this.content
      }
    }, 30000)
  }

  aboutToDisappear(): void {
    if (this.autoSaveTimer !== -1) {
      clearInterval(this.autoSaveTimer)
      this.autoSaveTimer = -1
    }
  }

  onBackPress(): boolean {
    if (this.content !== this.savedContent) {
      this.notice = '还有未保存内容，请先保存或清空后离开'
      return true
    }
    return false
  }

  private saveContent(): void {
    this.savedContent = this.content
    this.notice = this.content.length === 0 ? '空内容不需要保存' : '内容已保存'
  }

  private hasUnsavedContent(): boolean {
    return this.content !== this.savedContent
  }

  private clearContent(): void {
    this.content = ''
    this.savedContent = ''
    this.notice = '内容已清空，可以直接返回'
  }

  build() {
    Column({ space: 18 }) {
      Text('工单备注')
        .fontSize(26)
        .fontWeight(FontWeight.Bold)
        .width('100%')

      TextArea({ placeholder: '输入处理过程、异常原因或下一步动作', text: this.content })
        .height(180)
        .fontSize(16)
        .backgroundColor('#FFFFFF')
        .borderRadius(10)
        .onChange((value: string) => {
          this.content = value
          this.notice = value === this.savedContent ? '内容未变化' : '有未保存内容'
        })

      Row() {
        Text(this.notice)
          .fontSize(14)
          .fontColor(this.hasUnsavedContent() ? '#B26A00' : '#2E7D32')
        Blank()
        Text(`${this.content.length} 字`)
          .fontSize(14)
          .fontColor('#666666')
      }
      .width('100%')

      Row({ space: 12 }) {
        Button('保存')
          .layoutWeight(1)
          .onClick(() => {
            this.saveContent()
          })
        Button('清空')
          .layoutWeight(1)
          .backgroundColor('#E8EAED')
          .fontColor('#222222')
          .onClick(() => {
            this.clearContent()
          })
      }
      .width('100%')
    }
    .width('100%')
    .height('100%')
    .padding(20)
    .backgroundColor('#F6F8FB')
  }
}

为什么不要在销毁时改状态

第一，销毁阶段的 UI 更新没有业务意义。 组件已经要离开页面了，用户看不到你最后一次改出来的状态，反而增加框架调度成本。

第二，保存动作需要失败反馈。 真正的保存可能失败，比如网络断开、权限不足、服务端校验不通过。放在 aboutToDisappear 里做，用户已经离开，很难给出明确处理。

第三，返回拦截应该是页面决策。 onBackPress() 可以返回 true 拦截默认返回，这比销毁阶段再判断要可靠得多。

可以放进 aboutToDisappear 的事情

• 停止 setInterval、setTimeout
• 取消事件订阅或观察者
• 关闭不再需要的资源句柄
• 写一条非 UI 的调试日志

不建议放进去的事情：

1. 修改 @State 或 @Link。 容易制造销毁阶段刷新。
2. 弹窗要求用户确认。 交互时机已经太晚。
3. 发起关键保存请求。 失败后无法自然恢复。
4. 重新路由跳转。 页面栈会变得难推断。

返回链路怎么安排

如果真实保存依赖网络，saveContent() 里还要处理加载态和失败态。不要把这类可能失败的动作放到销毁阶段，否则用户离开后才失败，体验和数据一致性都会变差。

复盘问题时先看动作来源

如果页面离开时出现状态异常，不要先怀疑框架，先把动作来源捋清楚。用户主动点击保存、清空、返回，这些都属于明确动作，可以更新 UI 状态；组件进入销毁流程，已经不是适合继续组织交互的时机。

计时器 id 用普通字段保存也更合适，因为它本身不参与界面展示。autoSaveTimer 的职责只是帮助我们在 aboutToDisappear 里找到并清理定时器，不需要触发页面刷新。

保存逻辑尤其不要拖到销毁阶段。只要保存可能失败，就必须让用户还停留在可处理的页面里，这样才能重试、修改内容或取消离开。

复盘问题时先问三句

1. aboutToDisappear 里有没有改 @State、@Link？
2. 保存动作有没有可能失败，失败时用户是否还在当前页面？
3. 返回拦截是否发生在页面还能响应用户的时候？

结论

HarmonyOS7 的生命周期写得稳，关键不是记住更多回调，而是分清每个回调的职责。aboutToDisappear 最适合做安静的清理工作；凡是会影响 UI、会影响用户决策、会失败需要提示的逻辑，都应该提前处理。