HarmonyOS7 TextInput 表单校验别拖到提交时：错误要贴着字段走

前言

登录表单如果所有错误都等到提交时再提示，用户会一次看到一堆红字，还得自己倒回去找哪一项错了。更糟的是，按钮明明可以点，点完才说不符合规则，这种体验很容易让人烦。

HarmonyOS7 写 TextInput 时，我会把字段值、错误文案、提交状态分开。输入中做轻量校验，提交时做完整校验。表单校验不是最后一段 if，而是整个输入流程的一部分。

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

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

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

字段状态怎么拆

以手机号登录为例，手机号和验证码都需要值，也都需要错误文案。协议勾选则影响按钮是否可用。

错误文案要靠近对应字段，不要统一塞到页面顶部。用户改表单时，眼睛会跟着输入框走。

先把页面目标想清楚

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

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

完整 ArkTS 示例

@Entry
@Component
struct LoginFormPage {
  @State phone: string = ''
  @State code: string = ''
  @State agree: boolean = false
  @State phoneError: string = ''
  @State codeError: string = ''
  @State submitted: boolean = false

  private validatePhone(): boolean {
    if (this.phone.length === 0) {
      this.phoneError = this.submitted ? '请输入手机号' : ''
      return false
    }
    const valid: boolean = this.phone.length === 11
    this.phoneError = valid ? '' : '手机号需要 11 位'
    return valid
  }

  private validateCode(): boolean {
    if (this.code.length === 0) {
      this.codeError = this.submitted ? '请输入验证码' : ''
      return false
    }
    const valid: boolean = this.code.length === 6
    this.codeError = valid ? '' : '验证码需要 6 位'
    return valid
  }

  private canSubmit(): boolean {
    return this.phone.length === 11 && this.code.length === 6 && this.agree
  }

  private submit(): void {
    this.submitted = true
    const phoneOk: boolean = this.validatePhone()
    const codeOk: boolean = this.validateCode()
    if (!phoneOk || !codeOk || !this.agree) {
      return
    }
    // 这里可以继续发起登录请求
  }

  build() {
    Column({ space: 12 }) {
      Text('手机号登录')
        .fontSize(24)
        .fontWeight(FontWeight.Bold)
        .width('100%')

      TextInput({ placeholder: '请输入手机号', text: this.phone })
        .type(InputType.PhoneNumber)
        .maxLength(11)
        .onChange((value: string) => {
          this.phone = value
          this.validatePhone()
        })
      if (this.phoneError.length > 0) {
        Text(this.phoneError)
          .fontSize(12)
          .fontColor('#D32F2F')
          .width('100%')
      }

      TextInput({ placeholder: '请输入 6 位验证码', text: this.code })
        .type(InputType.Number)
        .maxLength(6)
        .onChange((value: string) => {
          this.code = value
          this.validateCode()
        })
      if (this.codeError.length > 0) {
        Text(this.codeError)
          .fontSize(12)
          .fontColor('#D32F2F')
          .width('100%')
      }

      Row({ space: 8 }) {
        Checkbox()
          .select(this.agree)
          .onChange((value: boolean) => {
            this.agree = value
          })
        Text('我已阅读并同意用户协议')
          .fontSize(13)
          .fontColor('#666666')
      }
      .width('100%')

      Button('登录')
        .width('100%')
        .enabled(this.canSubmit())
        .onClick(() => this.submit())
    }
    .padding(20)
  }
}

把关键代码一段段拆开

validatePhone() 和 validateCode() 同时服务输入中校验和提交校验。规则只有一份，后面改成正则校验或接口校验时，不会出现按钮判断和提交判断不一致。

submitted 用来控制空值提示。页面刚打开时，手机号为空是正常状态，不应该马上显示“请输入手机号”。用户提交过以后，再展示空值错误就合理了。

canSubmit() 只决定按钮可不可点，不代表提交时可以跳过校验。真实项目里状态可能被异步修改，提交入口仍然要再验一次。

什么时候提示错误

输入过程中适合提示格式类错误，比如手机号长度不够、验证码位数不够。空值错误适合在提交后出现，否则用户刚进入页面就看到一堆错误，会很别扭。

如果字段很多，可以把每个字段抽成一个小组件，但校验规则最好仍然集中管理。表单最怕每个输入框各写一套判断，最后改规则时到处找。

新手最容易踩的坑

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

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

放进真实项目还要补什么

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

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

写在最后

TextInput 不是只负责拿到字符串。好的表单会告诉用户当前能不能继续、哪里需要修改、错误为什么出现。把错误贴着字段走，用户少返工，代码也更容易维护。