表单实时校验结构与反馈设计详解

异步校验（如用户名唯一性）必须区分“校验中”和“校验失败”状态

用户输完立刻发请求，但网络有延迟。如果只在成功/失败后更新 UI，中间空白期会让人困惑：“到底有没有在检查？”

关键不是“能不能做”，而是“怎么让用户感知进度”。纯前端正则校验可同步执行，但涉及服务端的，必须暴露中间态。

实操建议：
• 提交前禁用提交按钮，或添加 data-loading 属性配合 CSS 禁用态
• 异步开始时立即添加 is-pending 类，显示加载图标或灰化提示
• 接口返回后，移除 is-pending，再根据结果添加 is-valid 或 is-invalid
• 错误提示文案要具体，比如 “该用户名已被注册”，而不是 “校验失败”

focus/blur 仍需保留，用于聚焦引导与无障碍支持

光靠 input 事件不能替代 focus 和 blur。前者负责“内容变化”，后者负责“交互意图”：用户刚点进来时，可能需要清空 placeholder 提示；离开字段时，即使没改动，也该做一次终审（比如邮箱格式最后确认）。

更重要的是，屏幕阅读器依赖 focus 顺序和 aria-invalid 属性播报错误，纯 input 事件无法满足 WCAG 要求。

实操建议：
• focus 时移除 is-invalid（清空旧错误，避免干扰当前输入）
• blur 时强制执行一次完整校验，尤其对未触发过 input 的空字段
• 动态设置 aria-invalid="true" 和 aria-describedby 指向错误文案 ID
• 不要用 title 属性做错误提示——它不被所有读屏器识别，且会覆盖原生 tooltip

最易被忽略的是多字段联动校验场景：比如“确认密码”必须等“新密码”非空且有效后才开始校验。这类逻辑不在单个 input 的事件里，得靠字段间状态订阅或集中式表单管理，硬塞进每个 input 的 handler 里只会让代码不可维护。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《表单实时校验结构与反馈设计详解》文章吧，也可关注golang学习网公众号了解相关技术文章。