前言

保存成功、复制完成、已加入收藏，这些用 Toast 很合适。它们不需要用户继续处理，只要给一个短反馈就够了。

但表单错误、网络失败、权限拒绝，如果也只靠 Toast，就很容易出问题。用户没看到提示，下一步还是不知道该怎么改。

Toast 适合轻提示，不适合承载关键错误。

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

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

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

先判断反馈是否需要用户处理

我的判断标准很简单：用户看漏了会不会影响下一步。

场景	推荐反馈	原因
保存成功	Toast	操作已经完成
标题为空	输入框下方错误文案	用户必须修改
网络失败	页面错误态加重试	用户需要继续处理
权限拒绝	页面说明加设置引导	用户需要知道替代路径

如果看漏也没关系，可以用 Toast。如果看漏会导致用户继续犯错，就必须把反馈留在页面上。

先把页面目标想清楚

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

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

完整 ArkTS 示例

下面写一个草稿保存页。标题为空时，错误贴在输入框下方；保存成功时，只弹一个 Toast。

import { promptAction } from '@kit.ArkUI'

@Entry
@Component
struct ToastFeedbackPage40 {
  @State title: string = ''
  @State content: string = ''
  @State titleError: string = ''
  @State saving: boolean = false

  async saveDraft(): Promise<void> {
    this.titleError = ''
    if (this.title.trim().length === 0) {
      this.titleError = '标题不能为空'
      return
    }
    this.saving = true
    try {
      await new Promise<void>((resolve) => {
        setTimeout(() => resolve(), 500)
      })
      promptAction.showToast({ message: '已保存草稿' })
    } finally {
      this.saving = false
    }
  }

  build() {
    Column({ space: 14 }) {
      Text('编辑草稿')
        .fontSize(26)
        .fontWeight(FontWeight.Bold)
        .width('100%')
      TextInput({ placeholder: '标题', text: this.title })
        .onChange((value: string) => {
          this.title = value
          if (value.trim().length > 0) {
            this.titleError = ''
          }
        })

      if (this.titleError.length > 0) {
        Text(this.titleError)
          .fontSize(12)
          .fontColor('#B42318')
          .width('100%')
      }

      TextArea({ placeholder: '正文', text: this.content })
        .height(160)
        .onChange((value: string) => { this.content = value })

      Button(this.saving ? '保存中...' : '保存草稿')
        .enabled(!this.saving)
        .width('100%')
        .onClick(() => this.saveDraft())

      Text('标题为空属于需要修正的问题，所以显示在输入框下方；保存成功只是轻反馈，用 Toast 就够。')
        .fontSize(14)
        .fontColor('#666666')
        .lineHeight(22)
        .padding(14)
        .backgroundColor('#FFFFFF')
        .borderRadius(12)
    }
    .padding(16)
    .width('100%')
    .height('100%')
    .backgroundColor('#F6F7F9')
  }
}

titleError 要贴着字段走

标题为空是用户必须修正的问题。它不能只弹一下 Toast，因为 Toast 消失后，用户还要猜到底哪里不对。

示例把 titleError 放在 TextInput 下方。用户看到错误位置，也知道该改哪个字段。

输入内容不为空时，错误会被清掉：

if (value.trim().length > 0) {
  this.titleError = ''
}

这种反馈比提交时统一弹错更友好。

保存成功才适合 Toast

保存成功不需要用户继续处理。用户只要知道操作完成了，就可以继续编辑或离开页面。

这时用 promptAction.showToast({ message: '已保存草稿' }) 很合适。它轻、不占页面空间，也不会打断用户。

但如果保存失败，就不能只弹 Toast。失败需要用户重试，页面应该留下错误文案和重试入口。

saving 防止重复点击

保存请求还没结束时，按钮应该禁用。否则用户连续点几次，可能发出多个保存请求，最后状态还不一定一致。

示例里 saving 同时控制按钮文案和可点击状态：保存中显示“保存中…”，并禁用按钮。用户能看到页面正在处理，也不会重复触发。

反馈可以分四层

页面反馈不要都用 Toast 解决。不同反馈有不同位置。

层级	适合场景	示例
字段级错误	表单项不合法	标题不能为空
页面级提示	非阻断问题	网络波动，内容已保留
阻断错误态	页面无法继续	加载失败，点击重试
轻提示	操作完成	已复制、已保存

反馈分层以后，用户会更清楚当前问题严重不严重，以及自己要不要处理。

Toast 使用时要克制

Toast 文案要短。不要把操作说明塞进 Toast，更不要连续弹多个 Toast。后一个提示会打断前一个，用户最后什么都没看清。

保存中也不建议弹“正在保存”。按钮状态更适合表达进行中，因为它和用户刚刚点击的动作绑定在一起。

Toast 最适合表达已经完成的小结果，而不是解释复杂问题。

新手最容易踩的坑

这一类示例最容易让人产生错觉：界面出来了，就以为已经掌握了。其实真正容易出问题的地方，通常都在效果之外，比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。

所以你练这篇内容时，别只看“现在能不能跑”，还要继续看“以后好不好改”。能把这个习惯养起来，你写出来的页面会比单纯照着示例拼出来的页面稳很多。

放进真实项目还要补什么

示例代码的重点是把核心思路讲明白，所以很多工程化细节会故意省掉。真正落到项目里时，你通常还要继续补接口联动、异常处理、边界保护、资源抽离，以及和其他页面状态之间的配合。

比较稳的做法是分三步走：先把结构和职责立住，再把真实业务接进去，最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”，而是真的更接近可以长期维护的业务代码。

写在最后

HarmonyOS7 页面里，把反馈按严重程度分层：轻的用 Toast，需要修正的留在字段旁，阻断流程的留在页面上。用户知道发生了什么，也知道下一步该怎么做。