做表单页面的时候，最不起眼又最容易翻车的，往往就是input输入框那几行校验逻辑。手机号格式不对、邮箱少了个@、用户名带上了空格，这些看似小问题，一旦放到线上就会变成一堆脏数据，轻则推送发不出去，重则后端接口直接报错。今天这篇就专门聊input输入框里的文本验证，从前端原生校验到JavaScript手写规则，再到实时反馈的交互细节，我把这些年做表单攒下来的经验和踩过的坑一起整理出来。
文章面向两类人：一类是刚接触前端、表单校验全靠百度拼代码的新手，另一类是已经做了两三年业务系统、想把手上的表单校验代码写得更规范的老开发。读完你不仅能拿到一套能直接抄的验证方案，更重要的是理解每条规则背后的取舍——为什么用这种写法、为什么放在这个时机触发、为什么正则要这么写才不会被绕过去。
1. 内容整体设计与思路拆解
1.1 文本验证在表单里到底解决什么问题
很多人觉得文本验证就是“检查一下输入对不对”，其实没那么简单。站在产品角度看，验证至少包含四个层次：第一层是格式验证，比如邮箱必须包含@、手机号必须11位数字；第二层是长度验证，比如用户名不能超过16个字符、密码至少8位；第三层是范围验证，比如年龄只能在0到120之间、评分只能是1到5的整数；第四层是业务规则验证，比如优惠码必须存在且未过期、用户名不能和已注册用户重复。
四层验证的优先级是递减的。格式和长度属于“硬校验”，任何用户都绕不过去，必须在前端做死；范围验证次之，通常用输入框的限制属性或者正则就能覆盖；业务规则验证最灵活，往往需要调接口，而且很多业务规则是复合性的——比如“手机号归属地和收货地址必须同省”，这种就不是一个正则能搞定的事。
设计文本验证方案的时候，先把需求拆成这四个层次，再逐层落地方案，思路会清晰很多。不然上来就写正则，写到一半发现逻辑对不上，返工成本极高。
1.2 验证时机：即时校验、失焦校验还是提交校验
文本验证最容易忽略的一件事是什么时候触发验证。同一个输入框，在按键时校验、在离开输入框时校验、在点击提交按钮时校验，体验完全不一样。
- 即时校验（input事件）：每次输入都校验，反馈最快，但用户还没输完就满屏飘红，心理压力很大，特别是长输入框（比如身份证号）体验尤其糟糕。
- 失焦校验（blur事件）：光标离开输入框时校验，是折中方案，适合必填项和存在明确格式要求的内容，比如邮箱和手机号。
- 提交校验：点提交按钮时统一校验所有字段，服务端返回错误再定位到具体字段。这种模式最传统，但问题在于错误反馈滞后，填写长表单时用户容易忘记之前的上下文。
真正好的交互设计不是三选一，而是组合使用：输入过程中做轻度校验（比如字符数计数、格式提示），失焦后做完整校验，提交前再做一次总校验兜底。我后面给出的示例代码就是按这个思路实现的，配合“是否已触碰该字段”的状态标记，才不会出现用户还没开始输入就报错的尴尬情况。
1.3 原生方案、正则方案还是框架方案，怎么选型
文本验证的技术选型，行业内基本分三派。
第一派是纯HTML5原生验证：用required、type="email"、pattern、minlength、maxlength这些属性，零JavaScript就能完成基础校验。优点是无依赖、浏览器原生支持，缺点是样式不可定制、提示文案受浏览器语言环境控制，而且不同浏览器的提示风格完全不统一，苹果手机和安卓手机弹出来的格式都不一样，很难做到品牌一致。
第二派是JavaScript手动验证：手写正则或校验函数，再配合setCustomValidity或自绘错误提示。优点是完全可控，想怎么提示就怎么提示，业务规则想写多复杂都行；缺点是代码量大，如果页面有几十个表单控件，纯手写会非常繁琐。
第三派是表单框架方案：比如Vue的VeeValidate、React的React Hook Form配上zod或yup，声明式地定义校验规则，框架自动管理错误状态。优点是开发效率高、规则复用性好，缺点是重依赖、学习曲线陡峭，一个轻量页面引入这么大一套东西杀鸡用牛刀。
我的建议是：没上前端框架的页面用方案二，写了原生JS也不复杂；上了框架的就直接用框架的校验生态，不要混着写。HTML5原生方案适合极简场景，比如只有一两个输入框的搜索页面，但不推荐用于注册、登录这类重要表单——那些原生弹出的英文提示在中文站点上看着就掉档次。
2. 核心细节解析与实操要点
2.1 HTML5原生校验属性能做到什么程度
先全面盘点一下HTML5给input框提供的校验能力，因为很多人只知道冰山一角。除了常见的required、type="email"、type="number"之外，还有几个容易被忽略的属性。
minlength和maxlength用于限制文本长度，需要注意的是maxlength是硬性截断——用户输入超过指定长度后，多余字符根本输不进去；而minlength只是校验不通过，并不会阻止输入，两者行为差别要牢记，否则会给产品经理带来“为什么这个框不能粘贴长文本”的困惑。
pattern属性接收一个正则表达式，但有个大坑：浏览器默认只做部分匹配，不做全匹配。比如pattern="[a-z]{4}"，它既能匹配“abcd”，也能匹配“abcd1234”，因为后者包含“abcd”这个子串。要让匹配完整，必须写pattern="^[a-z]{4}$"锚定开头和结尾。这个细节是网上教程里被提到得最多的，因为太容易踩了。
type="email"自带邮箱格式校验，但它的判断标准是HTML规范里的“有效邮箱”，比业务上常用的严格模式宽松得多——a@b这种在浏览器看来是合法的，因为规范上允许没有顶级域。如果你要求必须是带.的完整域名邮箱，光靠type="email"是不够的，还是得配合JavaScript。
2.2 正则表达式这样写，既防绕过的也防误伤
文本验证的核心技术点就是正则表达式。很多人写正则只考虑了“合法输入长什么样”，没考虑“非法输入有哪些变体”，导致规则很容易被绕过，或者反过来把合法输入误伤了。
以手机号验证为例。网上搜到的手机号正则五花八门，有写1[3-9]\d{9}的，也有写^1[3-9]\d{9}$的，区别就在锚定符号。没有锚定，用户在输入框里填“abcdef1xxxxxxxxxx”也会通过，因为正则只要找到匹配的子串就算过了。所有用于表单校验的正则，默认都应该加上^和$，除非你有特殊原因想进行子串查找。
再举一个常见例子——用户名校验。假设规则是“4到16位中英文、数字、下划线，不能以数字开头”，正则可以拆成两部分：首字符必须是字母或下划线[A-Za-z_]，后面跟着3到15位的合法字符[A-Za-z0-9_]{3,15}。合并起来就是^[A-Za-z_][A-Za-z0-9_]{3,15}$。拆开写的好处是逻辑清楚，以后加规则（比如禁止连续下划线）只需要改其中一段。
被误伤的典型是大小写和全角字符。用户可能在中文输入法状态下输入了全角数字１２３４５，正则\d匹配不上，就会误判。解决方案是校验前先做一次归一化处理：把全角字符转换成半角，再进正则。这里分享一个小函数：遍历字符串，如果字符编码在0xFF01到0xFF5E之间，减去0xFEE0就能得到对应的半角编码。
2.3 实时反馈的交互状态设计
文本验证交互做得好不好，核心在于状态管理。一个输入框至少应该有四种视觉状态：默认态、聚焦态、校验通过态、校验失败态。很多业务系统只做了失败态（红框加提示文字），成功态完全缺失，用户填写过程中没有正反馈，一个一个填下去心里越来越没底。
更细节的做法是引入一个“是否已触碰”的状态变量。用户第一次聚焦某个输入框就触发校验是不合适的——刚点进去当然是空值，立刻提示“不能为空”是在吓唬人。正确做法是：输入过程中只更新字符计数或格式小提示，等用户失焦后，或者输入框非空时，才开始展示完整的错误信息。
我用一个通俗类比来解释：表单验证就像教练盯你练车。你刚坐上驾驶座，教练就吼你“油门踩错了”，你肯定蒙了；但如果你已经开了一段路、教练看了你的操作再说哪里不对，你才听进去。同理，用户还没完成输入的输入框，就不要急着给它判死刑。
正反馈可以用简单的“绿色对勾”图标，也可以用输入框边框颜色变化来表达。错误提示文字不要频繁闪现，尽量固定在输入框下方的固定位置，避免布局抖动——那种每敲一个字错误提示就上下跳动的表单，是我见过最掉价的交互之一。
2.4 中文输入法的隐藏坑：composition事件
文本验证有个特别隐蔽的坑，叫做输入法组合事件。用中文输入法打字的时候，键盘敲下去的并不是最终上屏的字符，而是一个拼音组合过程——比如打“zhong”，过程中输入框里会先出现拼音，然后选字上屏。如果此时用input事件做校验，你会拿到一堆不完整的拼音，校验逻辑必然会误判。
这个问题的制式解法是监听compositionstart和compositionend事件。compositionstart触发时，设置一个标记，表示当前处于输入法组合状态；compositionend触发时清除标记。input事件触发时先看标记，如果处于组合状态，直接跳过校验逻辑。
let isComposing = false; input.addEventListener('compositionstart', () => { isComposing = true; }); input.addEventListener('compositionend', () => { isComposing = false; // 组合结束，此时再执行一次校验 validateInput(input); }); input.addEventListener('input', () => { if (isComposing) return; validateInput(input); });这个细节很容易被忽略，等到业务系统上线、运营人员用中文输入法录入数据时才发现校验结果不对，再回头排查就晚了。写通用表单组件的时候，这个坑一定要在封装前就处理掉。
3. 实操过程与核心环节实现
3.1 直接可抄的示例：带实时反馈的注册表单校验
下面这套是我在实际项目中用着很顺手的方案，包含用户名、邮箱、手机号三个典型字段的验证，兼顾了即时反馈和提交兜底。整个实现分为HTML结构、CSS样式、JavaScript逻辑三个部分，代码量不多，但是把前面聊到的设计思路全落地了。
先看HTML结构。注意我在form标签上加了novalidate，这是为了禁用浏览器自带的原生弹层提示，把校验行为完全接管到JavaScript上，避免原生提示和自定义提示叠加冲突。
<form id="registerForm" novalidate> <div class="form-field"> <label for="username">用户名</label> <input type="text" id="username" placeholder="4-16位字母或数字，不能以数字开头" autocomplete="off" > <p class="field-hint">4-16位字母或数字，不能以数字开头</p> <p class="field-error" aria-live="polite"></p> </div> <div class="form-field"> <label for="email">邮箱</label> <input type="text" id="email" placeholder="example@domain.com" autocomplete="off" > <p class="field-hint">请输入完整邮箱地址</p> <p class="field-error" aria-live="polite"></p> </div> <div class="form-field"> <label for="phone">手机号</label> <input type="tel" id="phone" placeholder="11位手机号" autocomplete="off" maxlength="11" > <p class="field-hint">仅支持中国大陆手机号</p> <p class="field-error" aria-live="polite"></p> </div> <button type="submit" class="submit-btn">立即注册</button> </form>这里有两个细节值得说明。一是aria-live="polite"属性，它告诉读屏软件错误提示出现时温柔地播报一次，照顾无障碍访问需求，这也是很多to B系统过合规检查的硬指标。二是邮箱输入框我故意用了type="text"而不是type="email"，因为我想用自定义正则做更严格的校验，手机弹出来的键盘类型不是这里关注的重点，如果你希望手机端弹出邮箱专用键盘，可以改成type="email"，校验逻辑不受影响。
3.2 样式细节：错误状态和成功状态怎么写不突兀
CSS样式主要控制三件事：输入框的边框颜色随状态变化、错误提示文字的显示与隐藏、成功提示的小图标。我习惯用类名驱动而不是行内样式控制，这样状态切换只要改className就行，逻辑和样式完全解耦。
.form-field { position: relative; margin-bottom: 18px; } .form-field input { width: 100%; height: 40px; padding: 0 12px; border: 1px solid #d9d9d9; border-radius: 6px; font-size: 14px; transition: border-color 0.2s ease; } .form-field input:focus { outline: none; border-color: #40a9ff; box-shadow: 0 0 0 2px rgba(64, 169, 255, 0.2); } .form-field .field-error { display: none; color: #ff4d4f; font-size: 12px; margin-top: 4px; } .form-field .field-hint { color: #8c8c8c; font-size: 12px; margin-top: 4px; } .form-field.is-invalid input { border-color: #ff4d4f; } .form-field.is-invalid .field-error { display: block; } .form-field.is-invalid .field-hint { display: none; } .form-field.is-valid input { border-color: #52c41a; }需要注意的是，默认状态下提示文字是灰色提示语，一旦校验失败，灰色提示语要被红色错误信息替换，不能两个同时显示，否则输入框下面两行文字容易混淆。边框颜色的过渡动画用了0.2秒的ease曲线，轻微柔和，不会让人觉得拖沓。成功和失败的颜色也要和整体设计语言一致——企业后台系统通常用蓝色系做主题，错误红色和成功绿色是标准色彩，不要自己发明新颜色。
3.3 JavaScript校验逻辑：规则表 + 触发策略分离
JavaScript部分是这套方案的核心，我用一个校验规则表集中管理所有字段验证函数，再用一个公共函数处理输入框的状态切换。新增校验规则时只需要在规则表里加一条，不需要改动其他代码，维护成本非常低。
const validators = { username(value) { if (!value) return '请输入用户名'; if (value.trim().length !== value.length) return '用户名不能包含首尾空格'; if (!/^[A-Za-z_][A-Za-z0-9_]{3,15}$/.test(value)) { return '用户名需为4-16位字母或数字，不能以数字开头'; } return ''; }, email(value) { if (!value) return '请输入邮箱地址'; if (value.length > 320) return '邮箱长度超出限制'; if (!/^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$/.test(value)) { return '邮箱格式不正确，请检查@和域名部分'; } return ''; }, phone(value) { if (!value) return '请输入手机号'; if (!/^1[3-9]\d{9}$/.test(value)) { return '手机号格式不正确，请输入11位号码'; } return ''; } };触发策略上，我维护一个touchedFields集合，记录哪些字段用户已经离开过。只有“被触碰过”或“已非空”的字段才展示错误信息，这样兼顾了实时反馈和不打扰。完整逻辑如下：
const form = document.getElementById('registerForm'); const fields = ['username', 'email', 'phone']; const touchedFields = new Set(); let isComposing = false; function showError(fieldName, message) { const field = document.querySelector(`#${fieldName}`).closest('.form-field'); const errorEl = field.querySelector('.field-error'); const input = field.querySelector('input'); field.classList.remove('is-valid'); if (message) { field.classList.add('is-invalid'); errorEl.textContent = message; } else { field.classList.remove('is-invalid'); errorEl.textContent = ''; } } function validateField(fieldName, showImmediately = false) { const input = document.getElementById(fieldName); const message = validators[fieldName](input.value.trim()); if (message) { if (touchedFields.has(fieldName) || showImmediately) { showError(fieldName, message); } return false; } showError(fieldName, ''); touchedFields.add(fieldName); if (input.value.trim()) { document.querySelector(`#${fieldName}`).closest('.form-field').classList.add('is-valid'); } return true; } fields.forEach(name => { const input = document.getElementById(name); input.addEventListener('compositionstart', () => { isComposing = true; }); input.addEventListener('compositionend', () => { isComposing = false; validateField(name); }); input.addEventListener('input', () => { if (isComposing) return; validateField(name); }); input.addEventListener('blur', () => { touchedFields.add(name); validateField(name, true); }); }); form.addEventListener('submit', (e) => { e.preventDefault(); fields.forEach(name => { touchedFields.add(name); validateField(name, true); }); const allValid = fields.every(name => validateField(name, true)); if (allValid) { // 这里执行真实的注册提交逻辑 // 实际项目中建议把收集到的字段值放到 FormData 里交给服务端 alert('所有字段验证通过，可以提交'); } else { const firstInvalid = fields.find(name => { return document.getElementById(name).closest('.form-field').classList.contains('is-invalid'); }); document.getElementById(firstInvalid).focus(); } });关于提交时的处理，有一个交互细节值得强调：当多个字段同时校验失败，要把焦点定位到第一个出错的输入框，并让浏览器滚动到该位置。用户体验上，表单校验失败后用户需要第一时间知道“从哪里开始改”，而不是逐个找红框。上面代码通过find找到第一个invalid字段并focus实现这个效果，实测下来比散落多个错误提示的做法清晰得多。
3.4 为什么用trim和长度上限组合，空格的坑别忽略
文本验证里最不起眼但又最影响数据质量的是空格处理。用户输入“ admin ”和“admin”，你存进数据库的值如果还带空格，后面做登录判断、查重都会出问题。
我的做法是分两步：第一步校验时把值用trim()去掉首尾空格再传给验证函数，这样/^[0-9]{11}$/这类正则不会被11位长度差值干扰；第二步是专门的空格规则，上面用户名校验里就有一个value.trim().length !== value.length判断，专门拦截首尾空格，如果产品要求不允许输入内部空格（比如用户名中间夹了空格往往会乱套），你在对应规则的第一个if里把空格敏感处理写进去即可。
此外，maxlength并不是唯一的长度限制手段。手机号我用maxlength="11"限制物理输入长度，防止用户多打字；邮箱我用了逻辑判断限制320字符。两种方式各有好坏：maxlength防呆但粗暴（粘贴长文本会被截断），逻辑判断柔性但用户输了很长才知道报错。我的经验是：必填字段、格式高度固定的字段（手机号、身份证号）用maxlength，自由文本字段（邮箱、地址）用逻辑校验，生产环境实测最顺。
3.5 一套工具函数：字符串像素宽度测量与截断
文本验证经常伴随一个隐藏问题：输入框太短，用户输入的文本超出可视宽度。比如邮箱地址长一点，输入框右边会被截断，看起来像是数据丢了，实际上只是视觉遮罩。处理方案是动态测量文本宽度，随时调配输入框的font-size或padding。
用Canvas测量字符串宽度是一个实用的小技巧：
function measureTextWidth(text, font) { const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); ctx.font = font; return ctx.measureText(text).width; } const input = document.getElementById('email'); const computedFont = getComputedStyle(input).font; input.addEventListener('input', () => { const width = measureTextWidth(input.value, computedFont); const inputWidth = input.clientWidth; if (width > inputWidth - 24) { input.style.fontSize = '13px'; } else { input.style.fontSize = '14px'; } });这个方案比scrollLeft来判断字符串是否超长更直观，而且不依赖于容器实测尺寸，你随时在任意输入框上套用。量宽度本身是高频同步操作，但现代浏览器处理Canvas测量性能相当好，几十个输入框的页面完全扛得住，实测没有卡顿感。
4. 常见问题与排查技巧实录
4.1 type="email"和自定义正则的八字不合
浏览器内置的type="email"有它自己的格式判定，当你同时使用pattern属性时，两条规则是“与”的关系——必须都通过才算通过。这会出现一种微妙场景：你写了pattern="^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"，按理说已经很严格了，但浏览器把a@b这种没有顶级域的地址内生判定为有效，于是pattern成了唯一限制器——因为type="email"的宽判定把你的窄规则放行了。
这两个属性撞在一起，调试起来非常麻烦。我的建议是二选一：要么纯用type="email"，接收浏览器内置判定；要么用type="text"加自定义正则，把控制权完全握在自己手里。别两个混用，否则你会浪费大量时间调试那些说不清是哪个校验在阻止提交的边界case。
4.2 手机号正则的“数字陷阱”和“号段更新”
手机号校验是反反复复被改需求的重灾区。刚上线时正则可能是^1[3-9]\d{9}$，用着用着新产品说“我们只支持4G号段”，于是改成^1(3[0-9]|4[5-9]|5[0-3-9]|7[0-9]|8[0-9]|9[0-9])\d{8}$；过两年又有新号段开放，又得加分支。这个过程中最常见的坑是正则分支顺序不注意导致误伤——比如15[0-3]和15[0-9]如果你先写了宽的，后面窄的永远不会命中（但反过来则不会误伤，只是逻辑冗余）。
实际上，对绝大多数业务系统来说，^1[3-9]\d{9}$已经够用了。你要明白产品真正关心的是“用户是否输成了乱码”，至于某个号段是否开放，那是运营商的事，前端校验管不了那么宽。如果某天真的碰到新号段被拒的反馈，改正则加一个分支就行，不必过度设计。
4.3 服务端校验永远不能省
这是我必须强调的一条红线。前端文本验证做得再漂亮，本质上也只是体验优化，不是真正的安全防线。一个懂技术的用户可以轻易绕过前端校验，直接向你的接口提交任意数据。真正能拦住脏数据和恶意注入的，是服务端的参数校验。
我在实际项目中见过太多次这样的教训：前端加了精巧的字符过滤和白名单，上线后运营平台被人用脚本扫接口灌了一堆恶意输入，数据库里乱七八糟。所以不管前端写了什么校验，后端拿到数据后必须重新验证：字段必填、格式匹配、长度边界、业务规则一个都不能少。两边的规则可以复用同一份正则描述，但校验职责必须分开，这只是工程常识，不是可选题。
4.4 无提示拦截与原生提示的取舍
有些产品经理要求“用户输错了就第一时间红框加提示文字”，有些则倾向于“用户犯错后提交才显示错误提示”。这两种设计背后，是对用户注意力的理解不同。我的经验是，注册登录页这种单列短表单，适合“失焦即提示”，因为字段数量少，试错成本低；但后台系统的长表单（比如客户资料管理、订单详情录入），更适合“提交时总校验”，中途少打扰，批量填写效率高。
当你要做“无提示拦截”时，记得maxlength不要设得太短，否则用户粘贴过来的长文本被静默截断，看起来就像系统吞了数据，容易引发工单。宁可让用户输入完整内容后通过校验规则提示“超出长度限制”，也不要物理截断造成数据丢失错觉。尤其是textarea或者可编辑div，这种不可见的截断造成的“数据神秘消失”问题，是我在客服工单里看到最多的投诉来源之一。
4.5 高频问题速查表
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 正则只匹配部分内容就通过 | pattern未加^和$，默认部分匹配 | 正则前后加上^和$锚定字符 |
| 中文输入过程中就报错 | 未处理输入法composition事件 | 监听compositionstart/end，组合期跳过校验 |
| 用户没输入就提示“不能为空” | blur或input事件里无条件执行校验 | 维护touchedFields集合，触碰后才显示错误 |
| 错误提示文字不停跳动 | 错误信息插入或移除导致布局变动 | 预留固定错误区域，用display切换而非动态插入节点 |
| 一个空格也被判定为合法 | 校验时未trim处理用户输入 | 先trim再正则匹配，且单独检查内部空格规则 |
| 粘贴长文本被无声截断 | maxlength限制且无错误提示 | 区分字段类型，用逻辑校验替代物理截断 |
| 不同浏览器提示样式不统一 | 依赖HTML5原生验证气泡 | 使用novalidate属性并完全接管校验 |
| 全角数字让正则失配 | 用户中文输入法状态下输入全角 | 校验前把全角字符归一化为半角 |
| 提交后浏览器跳到了奇怪位置 | 错误输入框未获得焦点 | 校验失败时focus到第一个错误值字段 |
这些问题是这几年我一个个踩出来的，每一条在特定场景下出现概率都不低。其中输入法组合事件和pattern部分匹配这两个，是最容易让新手摸不着头脑的——看起来都是“正则写对了但结果不对”，实际上一个跟浏览器正则语义有关，一个跟输入法事件循环有关，排查方向完全不同，希望这张表能帮你节省大把调试时间。
5. 一些个人的实操心得
表单验证写多了以后，我的直觉是：规则表与触发策略分离比什么都重要。验证函数只负责回答“这个字符串合不合法”，至于什么时候调用、错误信息怎么展示、成功状态怎么渲染，全由另一套机制管理。这样改前端UI、换主题、加字段，都不需要动校验逻辑，代码可维护性直接上了一个台阶。
另外有一个小技巧，给输入框命名时尽量用统一的语义化ID，比如username、email、phone，这样规则表和DOM查询可以保持一致的命名映射，不要出现v_2这种天知道是什么字段的ID。我见过太多上了年纪的业务系统，字段名早失效，文档也找不到，后来人改校验全靠肉眼猜，这种情况遇到一次就够痛苦了。
这个示例还有两个方向可以继续扩展：一是把错误提示改成气泡形式，浮在输入框右上方，表单比较紧凑的登录页、信息收集弹窗里很好用；二是给整张表单加一个“提交中”的loading状态，使用户体验完整闭环——校验通过不代表请求成功，网络超时、接口错误这些情况也需要有自己的提示文案体系。文本验证只是整个表单工程的开头，做透了它，后面的路自然顺。
