企业官网建设流程全解析

前言

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

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

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

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

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

字段状态怎么拆

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

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

先把页面目标想清楚

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

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

完整 ArkTS 示例

@Entry@Componentstruct LoginFormPage{@Statephone:string=''@Statecode:string=''@Stateagree:boolean=false@StatephoneError:string=''@StatecodeError:string=''@Statesubmitted:boolean=falseprivatevalidatePhone():boolean{if(this.phone.length===0){this.phoneError=this.submitted?'请输入手机号':''returnfalse}constvalid:boolean=this.phone.length===11this.phoneError=valid?'':'手机号需要 11 位'returnvalid}privatevalidateCode():boolean{if(this.code.length===0){this.codeError=this.submitted?'请输入验证码':''returnfalse}constvalid:boolean=this.code.length===6this.codeError=valid?'':'验证码需要 6 位'returnvalid}privatecanSubmit():boolean{returnthis.phone.length===11&&this.code.length===6&&this.agree}privatesubmit():void{this.submitted=trueconstphoneOk:boolean=this.validatePhone()constcodeOk: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=valuethis.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=valuethis.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不是只负责拿到字符串。好的表单会告诉用户当前能不能继续、哪里需要修改、错误为什么出现。把错误贴着字段走，用户少返工，代码也更容易维护。