表单异步校验怎么设计？触发时机、旧请求回包与提交状态

用户输入项目域名alpha，系统开始检查是否被占用；他又把域名改成beta。beta先返回“可用”，alpha随后返回“已占用”，输入框却被标成错误。用户看到的是beta，错误信息说的却是alpha。这不是文案不够友好，而是校验结果与当前输入失去了对应关系。

异步校验设计需要同时回答三个问题：什么时候开始检查，等待期间用户可以做什么，结果回来时是否仍然有效。本文用创建项目的域名字段走完这条路径，补充普通表单的基础设计方法里容易省略的时间顺序和提交边界。

先给校验分工，不要把每个字符都交给服务器

必填、长度和允许的字符通常可以在客户端先检查；域名是否被占用、优惠码是否仍有效、账号是否具备资格，则需要服务端数据。输入还不完整时就发送可用性请求，往往既浪费资源，也会让用户连续看到不必要的错误。

可以把域名字段的顺序定义为：先满足基础格式，再触发可用性检查，最后在创建项目时重新验证。前置检查提供及时反馈，提交校验决定业务是否真正成立。W3C表单验证教程明确提醒，客户端校验不能取代服务端验证；前端显示的绿色勾号也不应成为绕过最终检查的依据。

还要定义是否对输入进行标准化。例如域名忽略首尾空格和大小写时，字段展示、实际提交值与校验结果应对应同一规则。若系统悄悄把输入改成另一个值，用户无法解释为什么“看起来不同”的两次输入被判定为重复。

输入时、失焦后、提交时，各自承担什么任务

触发方式没有适用于所有字段的统一答案。密码强度可以在输入中提供渐进提示，必须输入完整格式的日期常常更适合失焦后判断。W3C表单反馈教程列举了这些差异。设计稿应逐字段指定策略，而不是在页面角落写一句“全部实时校验”。

若采用暂停输入后检查，需要与开发约定防抖策略；具体等待时长应结合输入节奏、网络与接口成本测试，不必把某个固定毫秒数当成体验标准。中文输入法还应等一轮组合输入完成，再对确定的文本处理，避免把拼音候选阶段当成最终值。

用一条时间线写清旧结果怎样失效

把前面的例子展开：第1步，输入alpha并发送请求A；第2步，改成beta，A对应的校验结果立即失效；第3步，发送请求B；第4步，B返回可用，界面显示beta可用；第5步，A返回已占用，但不再改变当前字段。有效性由请求对应的输入版本决定，不由谁最后到达决定。

开发可以使用请求序号、输入快照或其他一致性机制实现。设计交付无需指定框架，但必须写出验收目标：任何过期响应都不能改变当前值的错误、成功或校验中状态。旧请求的结束事件也不能提前关闭新请求的等待提示。

短信验证还多了一层“当前验证码”的版本关系：重新发送后，旧码和新码的反馈不能混用。验证码输入、重发与过期恢复进一步说明号码修改、粘贴输入和发送结果怎样衔接。

支持取消旧请求时，可以减少不必要的网络工作。AbortController文档介绍了浏览器可取消异步请求的能力。不过，取消不应成为唯一的一致性保障：请求可能已经完成，服务端也可能已进行处理，因此仍需判断响应是否属于当前输入。

输入由alpha改为beta再改回alpha，也需要新的输入版本。不能仅凭响应中的字符串碰巧与当前值相同，就认定一条很早的结果仍然有效；可用性可能随时间改变。是否复用短期结果、缓存多久，应根据业务风险明确约定。

把“校验失败”和“检查不到结果”分开

“该域名已被占用”是得到明确业务结论；“暂时无法检查域名”是网络或服务问题。后者不能显示成“域名不可用”，否则用户可能不断换名字，却永远解决不了问题。错误位置和恢复动作也不同：前者建议更换域名，后者提供重试或在提交时重新检查。

辅助文案、错误文案和等待图标应有固定的布局策略。异步消息每次出现都把后续字段往下推，会影响正在输入的用户；预留合理空间或采用稳定的说明区域，通常比不断弹出浮动提示更容易跟随。

字段依赖变化时，成功结果也要重新检查

域名可能只要求在当前团队内唯一，配送地址可能依赖所选国家，优惠码可能依赖购物车金额。此时校验依据并不是一个输入值，而是输入值加上相关条件。用户把团队从A切到B，即使域名没变，之前“可用”的结果也可能失效。

设计稿应列出依赖关系，并规定变化后的界面：哪些字段保留输入，哪些结果撤销，是否立即重查。不要为了省事清空整张表单，也不要保留一个已经没有依据的绿色勾号。用户应看到与当前团队一致的检查结果。

多字段远端验证尤其需要控制提示位置。起止日期范围错误属于两个字段的组合规则，可在日期组内给出整体说明；项目名重复则定位到项目名。一个页面只有顶部“参数错误”的反馈，无法帮助用户完成修正。

用户在校验途中提交，流程怎么继续

先判断远端检查是必需条件，还是辅助提示。必需条件尚未完成时，可以显示“正在检查，请稍候”并让本次提交等待；也可以由提交接口统一验证。辅助性检查暂时失败，不应无条件阻止可合法完成的任务。两种方案都要避免重复创建，并让用户知道点击已经被接收。

如果等待期间允许继续修改字段，正在提交的内容与画面上当前内容可能不同。如果业务提交请求尚未发出，可以锁定本次提交涉及的字段，或在修改后撤销这次提交意图并要求再次确认。业务请求已经发出时，停止前端等待并不能撤销服务端操作，应先确认提交结果，再决定是否允许重新提交。不能发送alpha，却在成功页面让用户以为创建的是beta。按钮的反馈可结合操作按钮反馈一起设计。

创建接口最终返回域名被占用时，保留其余已填信息，把错误放回域名字段，提供清楚的下一步。失败后恢复可操作的提交按钮，避免按钮一直停在“创建中”。若客户端超时而创建结果未知，应先确认任务状态，不能让一次重试变成两次创建。

错误摘要与字段提示要指向同一问题

较长的表单提交失败后，可以在上方列出错误摘要，并让每条错误链接定位到对应字段。GOV.UK错误摘要组件提供了这类结构的参考。摘要与字段旁的文字应一致；修正后两处同步更新，不要让顶部仍显示已经解决的问题。

异步校验不应在用户每次输入时强行移动焦点。普通状态变化可以通过合适的动态通知机制告知辅助技术；提交失败后，则按既定策略将焦点放到错误摘要或首个错误字段。结合无障碍检查清单，检查错误并非仅靠红色表达，提示与输入框也有明确关联。

同一字段有多个问题时，按解决顺序反馈

域名既含有不允许的空格，又可能与已有项目重复，优先提示用户能立即修正的格式问题，格式符合后再显示可用性结论。不要在同一个位置交替出现两条互不相关的红字。多项规则确实需要同时解释时，可以使用稳定的规则清单，但不要每输入一个字符就把整段内容重新播报。

浏览器自动填充、粘贴、清空和返回上一步也要经过相同的状态更新。只监听键盘输入容易漏掉这些路径。测试时可以先让字段显示可用，再粘贴另一个值，确认旧的成功标记会立即失效；清空字段后，也不能留下属于之前输入的“已占用”。这些细节不需要增加用户操作，却决定组件在真实填表过程中的一致性。

评审时故意让请求乱序，而不是只走成功路径

至少测试六条路径：连续输入两个不同值且旧请求晚返回；当前请求超时；修改依赖团队；校验中点击提交；校验成功后被其他用户抢先占用；提交结果未知后重新尝试。每条路径都记录当前输入、当前状态、允许动作和最终结果，测试才能判断是否符合设计。

可以在Pixso里搭建校验流程画板，把输入、校验中、占用、暂不可查、可用和提交冲突连接成一条项目创建流程，并在旁边画请求A与请求B的时间线。与B端表单的结构与反馈配合，组件负责一致的外观，画板上的规则负责解释时间变化，两者一起交付才容易落实。