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

文章目录前言为什么这个问题经常被写乱字段状态怎么拆先把页面目标想清楚完整 ArkTS 示例把关键代码一段段拆开什么时候提示错误新手最容易踩的坑放进真实项目还要补什么写在最后前言登录表单如果所有错误都等到提交时再提示用户会一次看到一堆红字还得自己倒回去找哪一项错了。更糟的是按钮明明可以点点完才说不符合规则这种体验很容易让人烦。HarmonyOS7 写TextInput时我会把字段值、错误文案、提交状态分开。输入中做轻量校验提交时做完整校验。表单校验不是最后一段 if而是整个输入流程的一部分。为什么这个问题经常被写乱TextInput 表单校验别拖到提交时 这类内容很容易被写成“代码能跑就算讲完了”但对初学者来说这恰恰是最不够的地方。真正让人卡住的往往不是某个组件名记不住而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。所以这篇文章不只想给你一个能跑的例子更想把背后的判断过程讲清楚。你只要把这个判断过程吃透后面自己改页面、补需求、查问题时心里会稳很多。字段状态怎么拆以手机号登录为例手机号和验证码都需要值也都需要错误文案。协议勾选则影响按钮是否可用。字段输入时处理提交时处理手机号限制长度提示位数空值和位数都要拦截验证码限制长度提示位数空值和位数都要拦截协议只影响按钮未勾选不能提交错误文案要靠近对应字段不要统一塞到页面顶部。用户改表单时眼睛会跟着输入框走。先把页面目标想清楚在真正写代码之前先别急着盯着 API。更有用的做法是先想清楚这个页面到底想解决什么问题用户最在意的反馈是什么哪些状态必须一直保持一致。当你先把这条主线想明白再回头看组件和状态设计很多选择都会顺理成章。对小白来说这一步尤其重要因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。完整 ArkTS 示例EntryComponentstruct LoginFormPage{Statephone:stringStatecode:stringStateagree:booleanfalseStatephoneError:stringStatecodeError:stringStatesubmitted:booleanfalseprivatevalidatePhone():boolean{if(this.phone.length0){this.phoneErrorthis.submitted?请输入手机号:returnfalse}constvalid:booleanthis.phone.length11this.phoneErrorvalid?:手机号需要 11 位returnvalid}privatevalidateCode():boolean{if(this.code.length0){this.codeErrorthis.submitted?请输入验证码:returnfalse}constvalid:booleanthis.code.length6this.codeErrorvalid?:验证码需要 6 位returnvalid}privatecanSubmit():boolean{returnthis.phone.length11this.code.length6this.agree}privatesubmit():void{this.submittedtrueconstphoneOk:booleanthis.validatePhone()constcodeOk:booleanthis.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.phonevaluethis.validatePhone()})if(this.phoneError.length0){Text(this.phoneError).fontSize(12).fontColor(#D32F2F).width(100%)}TextInput({placeholder:请输入 6 位验证码,text:this.code}).type(InputType.Number).maxLength(6).onChange((value:string){this.codevaluethis.validateCode()})if(this.codeError.length0){Text(this.codeError).fontSize(12).fontColor(#D32F2F).width(100%)}Row({space:8}){Checkbox().select(this.agree).onChange((value:boolean){this.agreevalue})Text(我已阅读并同意用户协议).fontSize(13).fontColor(#666666)}.width(100%)Button(登录).width(100%).enabled(this.canSubmit()).onClick(()this.submit())}.padding(20)}}把关键代码一段段拆开validatePhone()和validateCode()同时服务输入中校验和提交校验。规则只有一份后面改成正则校验或接口校验时不会出现按钮判断和提交判断不一致。submitted用来控制空值提示。页面刚打开时手机号为空是正常状态不应该马上显示“请输入手机号”。用户提交过以后再展示空值错误就合理了。canSubmit()只决定按钮可不可点不代表提交时可以跳过校验。真实项目里状态可能被异步修改提交入口仍然要再验一次。什么时候提示错误输入过程中适合提示格式类错误比如手机号长度不够、验证码位数不够。空值错误适合在提交后出现否则用户刚进入页面就看到一堆错误会很别扭。如果字段很多可以把每个字段抽成一个小组件但校验规则最好仍然集中管理。表单最怕每个输入框各写一套判断最后改规则时到处找。新手最容易踩的坑这一类示例最容易让人产生错觉界面出来了就以为已经掌握了。其实真正容易出问题的地方通常都在效果之外比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。所以你练这篇内容时别只看“现在能不能跑”还要继续看“以后好不好改”。能把这个习惯养起来你写出来的页面会比单纯照着示例拼出来的页面稳很多。放进真实项目还要补什么示例代码的重点是把核心思路讲明白所以很多工程化细节会故意省掉。真正落到项目里时你通常还要继续补接口联动、异常处理、边界保护、资源抽离以及和其他页面状态之间的配合。比较稳的做法是分三步走先把结构和职责立住再把真实业务接进去最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”而是真的更接近可以长期维护的业务代码。写在最后TextInput不是只负责拿到字符串。好的表单会告诉用户当前能不能继续、哪里需要修改、错误为什么出现。把错误贴着字段走用户少返工代码也更容易维护。