简介这是一份面向Web界面开发与设计人员的界面规范参考文档围绕Web Form的UI设计系统讲解界面设计的目的、适用范围、文件与控件命名规范、控件外观规范及字体、颜色、布局、图标等核心规范同时覆盖边距、尺寸单位、表格排版和网站目录结构等细节适合需要统一团队风格、提升协作效率的前后端开发者与设计师。压缩包内共1个doc文件约199KB轻量便携便于快速查阅。目前已有2517人学习下载。内容源自宏图财务内部规范包含版本修改记录从目录结构到表格高宽均有明确约定可直接作为团队制定Web界面规范的参考模板或入手蓝本。1. 做 Web 界面设计时大家最容易忽略的是 Web Form 的 UI 设计规范做 Web 界面设计时大家最容易忽略的是 Web Form 的 UI 设计规范表单往往被当成“拼控件”来对待。很多团队的产品评审会聊首页和列表页聊到表单却以“先这样放联调再调”收场。等前端真的把输入框连上接口问题才开始冒出来同一个表单的 label 一会儿在三行、一会儿在左侧必填星号时有时无错误提示红字顶开布局密码框的浏览器自动填充把背景变成刺眼的黄。更麻烦的是业务规则变化——新增一个“公司税号”字段时有人直接插在中间导致相关字段被拆到两屏。Web Form 的 UI 设计规范说到底是把表单当成“用户完成任务的一段对话”来设计而不是“放一批控件”。它要回答四个问题字段顺序和信息层级怎么排控件在不同状态长什么样错误和校验用什么方式出现以及这套规则如何在 web 项目里被低成本复用。适合后端顺手写页面、前端新人刚接手表单模块或正在引入 Element UI、Ant Design 这类前端 UI 框架但还缺内部约束的团队。2. 先定信息架构再画 Web Form字段分组与主次表单 UI 规范最先要约束的不是颜色和圆角而是信息架构。客户填写、业务接入、浏览器自动填充这三件事共用同一组字段如果字段顺序和分组不稳定后面所有样式和校验逻辑都会跟着返工。我一般会先画一张字段登记表而不是直接开 Sketch 或写 JSX。2.1 把字段拆成“问题”而不是“控件”要理解用户为什么填这张表业务负责人会告诉你是“收集客户信息”但用户心理上是“我要申请一个账号 / 下一张订单 / 领取一次试用”。所以字段顺序应该按回答的自然顺序走先身份再联系方式再业务参数最后索要授权或附加项。最反直觉的结论是很多表单把公司名称放在最前面但用户往往先知道自己叫什么不知道公司全称和税号是不是一致。字段顺序一变自动填表的成功率也会掉。具体做法把所有字段按“核心识别字段、联系方式字段、业务选项字段、补充信息字段”四组归类组内再排顺序。组与组之间用 fieldset 语义隔离既能在视觉上分组也能让读屏软件按组朗读。下面是最小可用的 HTML 结构建议新项目直接以它作为 Web Form 的骨架fieldset classform-group legend账号信息/legend div classform-row label forusername用户名/label input idusername nameusername autocompleteusername / /div div classform-row label foremail邮箱/label input idemail nameemail typeemail autocompleteemail / /div /fieldset这段代码的价值在于legend 让每个分组有一个可读名字读屏用户切到组时先听到“账号信息”再听到控件名autocomplete 让浏览器能正确映射用户资料。表单 UI 规范如果不控制字段的语义结构后面再加 title 属性和 aria-label 都很容易被漏掉。2.2 必填标识、默认值与推导字段的处理必填星号最常见的位置是 label 左侧还是右侧其实不同前端 UI 框架默认位置并不一致。我建议在规范里写清楚必填字段用required属性加星号并在 label 文本里保留自然语言“必填”这样读屏和截图都很明确。不要只用红色星号括起来因为色盲用户会忽略它。默认值要特别留意“推导字段”和“可选字段”的区别。比如“联系电话”和“验证码”之间有相互推导关系规范里应该标注哪个字段触发请求、哪个字段由服务端返回而不是让 UI 层猜测。下表是字段分类与处理策略我通常把它直接写进设计规范附录字段类型典型字段默认值策略UI 控件建议核心识别字段姓名、手机号、身份证号不设默认值允许浏览器自动填充单行文本宽度按内容上限联系方式字段邮箱、电话、地址不设默认值保存后回显邮箱用 typeemail地址用多行文本业务选项字段套餐、周期、数量必须有一个合理默认选项通常是推荐项单选按钮组或下拉框推导字段总额、积分、余额由后端计算回显禁止手动编辑只读文本或自定义只读控件补充信息字段备注、推荐码默认空避免多余字符进入业务库多行文本或链接弹窗表格里“推导字段”这点值得强调前端能算的金额往往会被用户质疑因为缺少服务端规则。规范里要把这类字段标成只读连光标都不能进去否则用户会试图改一个根本没有权限改的数字。2.3 提交按钮要出现在每一个决策点长表单和短表单的主按钮策略不一样。短表单只有一个主按钮放哪都行长表单如果用 tab 键或者滚动条用户常见困惑是“填完了保存按钮在哪”。我一般会在表单底部固定一个按钮排同时把“保存草稿”降级为次按钮禁止和主按钮并排抢视觉。还要注意不要只写“提交”按钮文案要带结果比如“注册并登录”“保存客户信息”。为了不牺牲可访问性按钮排通常放在/form内部用 flex 排列主按钮在最前或最右取决于平台习惯。如果表单区域是滚动容器可以把按钮排设置为 sticky让它在视口底部可见。这个技巧能直接提高填写长表单的完成率。提示按钮层级一旦定了后续不要在按钮组里加“重置”按钮。Web Form 的误操作风险里“重置”排第二仅次于“提交两次”。2.4 把键盘操作和 Tab 顺序写进规范读屏和键盘用户依赖 Tab 在字段间移动。Web Form 的天然 DOM 顺序就是 Tab 顺序所以规范里要禁止用 CSS 重排表单行。常见错误是 flex 的order属性调整某一行在视觉上的位置但 DOM 顺序没变键盘用户听到的顺序和看到的完全不同。另一个易踩的坑是“隐藏电话号码”的折叠区如果折叠状态用display:none控制里面的字段自然脱离 Tab 顺序这是正确的但如果只是用opacity:0或visibility:hidden控制Tab 仍然能聚焦进去读屏也会读到。规范里可以直接写明折叠内容统一用hidden属性或[hidden]显示规则禁止用透明/位移方式隐藏表单控件。此外每个输入框的 label 必须关联控件for和id一一对应。很多人为了方便直接把 label 包在控件外层虽然也可点但 for/id 关联在读屏上更可靠我建议当成规范强制项。3. 用前端 UI 框架把 Web Form 的界面规范定成组件理论确定后落到实现。如果项目里已经引入了 Element UI、Ant Design、daisyUI 这类前端 UI 框架不等于可以省略规范。框架只给控件默认样式真正属于业务的约束——控件在表单里的最小高度、圆角、焦点颜色、禁用透明度、行间距——必须由项目自己的 token 层定义。我一般会先统一“尺寸、间距、状态”再让组件消费这套 token而不是让每个页面手写 margin。3.1 用 CSS 变量锁定输入控件的最小规格一个输入框的“手感”由高度、字号、圆角、边框颜色和 padding 共同决定。高度太矮手指点不准太高列表页的筛选区又占屏。常见的企业 web 项目我会先定一个基础尺寸体系参考 Element UI 中文官网里 Form 表单组件的行为再抽出自定义的 CSS 变量因为框架默认的 token 属于 demo 场景不一定符合业务密度需求:root { --form-control-height: 36px; --form-label-width: 96px; --form-gap: 16px; --form-error-color: #e5484d; --form-border-color: #cbd5e1; --form-focus-ring: 0 0 0 2px rgba(37, 99, 235, 0.25); --form-radius: 6px; }这些变量不是拍脑袋定出来的36px 的输入框高度能兼顾触屏下限和桌面端紧凑筛选区label 宽度 96px 在中文场景下能盖住大部分“手机号”“公司税号”等较长标签。参数值建议在规范里用表格说明应用范围避免有人为了“更整齐”把所有 input 都给 200px 宽度。3.2 栅格与字段宽度宁可一列不要硬凑两列Web Form 的字段宽度最稳的方案是主字段占满可用宽度短字段按内容收窄。不要为了让网格好看把“所在城市”和“详细地址”强行排成同一行。这里我推荐用 CSS Grid 的命名区域而不是 flex 一行到底因为在换行和 label 对齐上Grid 的可控性更好。一个常见的最小表单栅格.form-grid { display: grid; grid-template-columns: repeat(12, minmax(0, 1fr)); gap: var(--form-gap) var(--form-gap); } .form-item { grid-column: span 12; } .form-item--half { grid-column: span 6; } .form-item--third { grid-column: span 4; } media (max-width: 768px) { .form-item--half, .form-item--third { grid-column: span 12; } }这里的 12 列栅格是给页面框架规则用的表单内部只需要四种跨度12、6、4、按文本长度自适应。参数说明gap 同时定义行距和列距避免字段间出现 8px 和 24px 混排minmax(0, 1fr)防止长 label 或长数字把列撑爆。小屏幕下全部回到单列这是表单 UI 规范的底线。3.3 状态不只 hover 和 focus把可读、只读、禁用、错误分清楚最容易漏的是“只读态”。很多项目只写了禁用态于是把只读框直接套用disabled结果值变灰、复制不了、读屏也不读。规范里要单列“只读态”只读输入框保留文字颜色去掉光标和边框高亮允许选中复制“禁用态”才是整体降透明度并且在注释里写明为什么禁用。两者在外观上应有明确区分。下面这张状态表是常见做法可直接用于组件的验收自检状态边框文字颜色背景交互默认--form-border-color常规正文色白色可点击不触发错误提示悬停深一档灰色不变不变提示可编辑焦点蓝底 焦点环不变不变键盘可见错误环优先级更高只读淡灰实线不变#f8fafc可选中不可修改禁用淡灰虚线降透明 50%#e2e8f0不可点击tab 可达但不可改错误红色不变#fff5f5显示错误信息焦点优先定位第一处表格里的“焦点环”值得作为规范强制项只用边框颜色变化显示焦点在团队演示和 checkbox 场景里很容易被忽略。CSS 中可以用outline或box-shadow实现但注意不要一层focus: border-color就算完成至少保留 2px 的可见焦点环这是键盘可访问性的最低要求。3.4 列表筛选区与数据录入表单是两种密度同一个 web 项目里筛选区和录入表单共用输入控件但不该共用相同的密度。筛选区通常只有一行追求“一眼看到全局”字段高度可以降到 32px间距缩到 12px数据录入表单需要长时间阅读高度保持 36px间距 16px。常见的错误是筛选区用主表单的大间距结果一屏放不下 4 个筛选项用户被迫滚动。规范里建议按“筛选表单”“普通表单”“长表单”三个场景各出一套尺寸而不是只出一个基准值。框架组件可以通过传入size属性区分。4. 校验与错误反馈Web Form 体验的“临门一脚”用户把表单填完不代表任务成功。校验时机、错误文案、服务端错误排布这三样比控件样式更影响完成率。很多前端工程师喜欢在 input 事件里实时校验结果用户正在输入手机号第 7 位时就飘红这种“校正在打断输入”的失败体验比不校验还糟。4.1 校验时机失焦校验 提交兜底实时校验只用于特定字段日常表单最常见的时机组合是输入时只做格式提示先不急失焦时做完整校验提交时把所有字段再校验一遍并聚焦到第一个错误项。密码强度、用户名唯一性这种“异步查询”字段才用防抖实时校验。下面是一个可用的校验触发代码用原生 JS 表达不依赖大框架const form document.querySelector(#orderForm); form.addEventListener(submit, (event) { const firstInvalid form.querySelector([aria-invalidtrue]); if (!form.checkValidity() || firstInvalid) { event.preventDefault(); firstInvalid?.focus(); } }); document.querySelectorAll([data-validate-on-blur]).forEach((control) { control.addEventListener(blur, () { // 只校验这个控件避免整个表单其他未填写字段全部红起来 validateControl(control); }); }); function validateControl(control) { if (!control.checkValidity()) { control.setAttribute(aria-invalid, true); // 把错误信息绑定到控件读屏可以朗读 document.querySelector(#${control.id}-error).textContent control.validationMessage; } else { control.removeAttribute(aria-invalid); } }参数说明checkValidity()是浏览器内置约束验证凡是写了required、typeemail、pattern的控件都会在提交时自动校验aria-invalid告诉辅助技术这里有错误配合错误文本节点实现程序化提示。防抖仍然建议交给框架或工具函数做原生setTimeout500ms 即可但要注意同字段的异步请求可能乱序返回需要记录最新一次请求的序号再决定是否展示结果。4.2 错误信息怎么写位置、原因、修复路径错误信息是 UI 的一部分不是一句话越短越好。好的错误文案要满足说明哪个字段、为什么失败、怎么改。常见反例是“提交失败”“请检查输入”用户根本不知道是邮箱格式错还是密码短了。个人建议采用“字段名 约束 示例”模板例如“手机号不是有效的 11 位号码例如 13800138000”“密码需要 8-20 位且同时包含字母和数字”“税号与所选国家/地区不匹配请重新选择地区”错误信息和控件之间的位置关系我倾向于“错误信息出现在相关控件下方而不是控件右侧或表单顶部”。因为右侧在窄屏会折行顶部需要用户回找。如果一行有多个字段错误信息必须与对应控件通过aria-describedby关联并在控件下方用红色小字显示同时控件边框变红。下表是几类常见的错误处理模板可以直接抄进规范错误类型推荐文案模板展示位置必填为空“请输入{字段名}”控件下方格式错误“{字段名}格式不正确例…”控件下方长度超限“{字段名}不能超过 {N} 个字符”控件下方逻辑冲突“{字段A}和{字段B}不能同时选择”表单顶部 第2个相关控件服务端失败“保存失败{服务端返回原因}”表单底部错误条4.3 服务端校验兜底禁止只做前端拦截前端校验永远可绕过且可被异常事件跳过任何业务校验都必须在服务端做第二道线。Web Form UI 规范里要规定前端校验失败时不再发起请求前端校验通过但服务端返回错误时把响应里的code、message、fieldName映射到具体输入框并在焦点上标红。常见做法是让接口统一返回这样的 JSON{ code: 40030, message: 邮箱已被注册, field: email }前端拿到field后把错误信息塞进该字段的错误节点并触发一次 focus。注意不要直接把message显示到表单顶部就结束用户要跑到顶部看完再回来找输入框这不叫 UI 规范叫让用户做阅读理解。另外提交按钮在请求期间要进入 loading 态并禁用防止重复点击。4.4 提交状态要把“按钮 loading”做成标配用户可以双击提交按钮或按两次回车导致同一表单提交两次。规范要求提交前置为 loading 态按钮文案变“提交中…”同时按钮和所有字段都禁用阻止第二次触发。有一种错误做法只是给按钮加一个半透明遮罩但按钮仍可点击。另外如果表单里包含文件上传loading 态还需要显示上传进度而不是只给一个转圈。提交完成后无论成功失败都要结束 loading失败时恢复可编辑成功时按业务跳转或清空。5. 用“间距尺度 状态 token”统一所有表单的最后一公里上面四章讲了规范怎么定最后一章讲一个性价比特别高的执行套路只做两件事一是统一间距尺度二是统一状态 token。间距尺度用 4px 基准4、8、12、16、24、32、48 这七个档位覆盖 Web Form 里所有边距、间距和分组间隙。为什么是 4 的倍数主流浏览器、设计工具和 CSS 栅格的最小单位都能整除表单上也不会出现 13px 这种“看起来就是手抖调出来的”距离。字段之间的垂直间距用 16px标签和输入框间距用 8px分组之间的分隔用 24px卡片外层留 32px。这套数字写进规范后新同学做页面时不用再纠结 margin 到底给多少。状态 token 建议在 CSS 变量层固化而不是把状态分散到每个组件文件。我通常把表单状态折叠成五个语义 token--form-border-strong、--form-border-focus、--form-border-error、--form-fill-readonly、--form-fill-disabled。组件里只消费 token不出现具体色值。验证方式可以用一个简单的 Playwright 脚本断言焦点环可见我一般会把这些检查加进 CI// playwright 片段检查 Web Form 的焦点环是否可见 const input page.locator(#username); await input.focus(); const outline await input.evaluate((el) getComputedStyle(el).outlineStyle); await expect.poll(() outline).toBe(solid);代码里标出的技术点getComputedStyle 拿到 outline 不为 none说明键盘可见性至少没有被 CSS 清零。另一个更省事的验证是 CtrlA 全选表单后按 Tab能依次看到焦点环沿 label、输入框、按钮顺序移动中途如果焦点环跳到地址栏或消失说明 tabindex 或 disabled 用错了。把间距尺度和状态 token 固定下来Web Form 的 UI 设计规范才真正从文档变成可执行的东西。后续无论接 Element UI 的中文文档组件还是换成 DaisyUI、React Aria都可以在这些框架之上覆盖一层 token让第三方组件看起来和你自己的设计语言一致升级框架时只需要改 token 映射表页面组件不需要逐个检查状态。本文还有配套的精品资源点击获取