表单组件设计完整规范：状态、校验、反馈与协作边界一次讲清

很多团队在做设计系统时，最容易高估“有组件”这件事的完成度。

输入框、选择器、日期组件、提交按钮都做出来了，看起来像是拥有了一套表单能力。但只要一进入真实业务，很快就会出现这些问题：

• 同样是必填错误，不同页面的提示位置和语气完全不同
• disabled、readonly、loading、invalid 的行为定义各不相同
• 设计稿里只有静态样式，没有校验节奏和异常场景
• 组件 props 越来越多，但谁也说不清哪些是规范能力，哪些只是历史兼容

所以这篇文章不再讲“表单组件有哪些”，而是专门讲规范：怎样把表单组件做成一套可协作、可扩展、可回归的系统。

如果你想先补组件体系基础，可以先看 表单组件设计系统完全指南、复杂表单业务逻辑管理 和 Vue 做落地页结构、表单、埋点。

先定义 4 类状态，不然后面所有讨论都会混乱

表单规范的第一步，不是写样式，而是先把状态语言统一。

我更建议每个基础字段都至少定义这 4 类状态：

很多系统把 loading 和 success 也塞进字段状态里，但更稳的做法是把它们定义为“表单级反馈”或“提交级反馈”，不要让单字段状态无限膨胀。

校验规范最怕的不是规则少，而是时机乱

同一条规则，如果在不同时间点触发，体验完全不同。

建议把校验分成三层：

1. 输入期：字符数、格式趋势、密码强度
2. 失焦期：邮箱、手机号、日期格式这类可立即判断的问题
3. 提交期：跨字段依赖、业务约束、服务端校验

这背后的原则是：

• 用户还在输入时，不要过早打断
• 用户离开字段时，要给出明确且可行动的反馈
• 提交时，再处理真正需要整体判断的规则

如果团队不把触发时机写进规范，最终每个业务线都会按自己的“感觉”实现。

错误提示不是文案问题，而是路径问题

很多表单体验差，不是因为颜色不好看，而是因为用户不知道下一步做什么。

一个更可靠的错误提示规范应包含 3 件事：

• 指出哪里错了
• 说明为什么错
• 告诉用户如何改

例如：

• 不推荐：输入无效
• 更可用：邮箱格式不正确，请检查 @ 和域名是否完整

如果是服务端错误，还应区分：

• 字段级错误：靠近字段展示
• 表单级错误：放在提交区或顶部摘要
• 系统级错误：用 toast 或全局提示，避免混淆为用户填错

组件 API 要控制在“表达清楚”，不要无限兼容

表单组件最常见的失控方式，是 props 越加越多。

建议在规范里明确分层：

这样做的好处是，基础组件不需要知道所有业务文案和复杂校验，业务层也不会反过来污染基础能力。

失败案例：把所有表单差异都压进一个万能组件

很多团队都做过一个叫 FormField 或 BaseInput 的超级组件，最后支持：

• 左右图标
• 多种 label 布局
• 各类校验时机
• 多种异步查询
• 字段联动
• 业务埋点

结果是：

• 文档很难写清楚
• 改一个状态影响多个业务
• reviewer 很难判断回归范围

更稳的方式是：

• 基础字段组件只做输入行为
• 规范组件统一承载 label/help/error
• 复杂业务场景另做组合层封装

不要把“组件复用”误解成“所有变化都塞进同一个组件”。

设计与前端的协作边界也要写进规范

真正能长期落地的表单规范，不会只停留在 Figma 或代码仓库里，而会把双方责任讲清楚：

• 设计负责：视觉层级、状态稿、错误样式、间距和层级规则
• 前端负责：组件 API、状态机、校验节奏、无障碍行为
• 产品负责：哪些字段必须收集、哪些校验属于业务约束

如果三方没有共识，最后最容易变成“设计只有静态稿，前端靠猜补动态逻辑”。

一份可直接复用的检查清单

• 基础字段是否定义了 default、focus、invalid、disabled/readonly 状态
• 校验触发时机是否写清输入期、失焦期、提交期
• 错误提示是否能指导用户修正，而不是只给抽象判断
• 字段级错误和表单级错误是否有清晰分工
• 组件 API 是否控制在基础能力边界内
• 设计稿里是否包含空态、错误态、加载态和成功反馈
• 无障碍细节是否覆盖 label 关联、错误朗读、键盘操作

总结

表单组件的真正难点，从来不是样式，而是规范。只有把状态定义、校验时机、错误路径、API 边界和协作分工一起写清楚，表单系统才会从“重复救火”走向“稳定复用”。

进一步阅读：

• 表单组件设计系统完全指南
• 复杂表单业务逻辑管理
• 无障碍设计指南