系统化html表单规范必须围绕语义正确、可访问可用、提交可控、验证可维护四目标构建约束链；label与for/id须显式配对；form method/enctype/action需按场景锁定；fieldset+legend为分组刚需；按钮须用button[type]显式声明。
直接说结论：系统化 HTML 表单规范不是堆砌标签，而是围绕「语义正确、可访问可用、提交可控、验证可维护」四个刚性目标建立约束链——缺一环，表单就可能在屏幕阅读器里失声、在 Safari 里提交失败、或在用户填到一半时丢数据。
label 和 for/id 必须成对出现，不能靠包裹偷懒
很多人用 <label>用户名<input name="user"></label> 看似省事，但实际会破坏辅助技术的焦点映射逻辑。屏幕阅读器依赖 for 属性精准绑定输入项，包裹写法在部分旧版 JAWS 或 VoiceOver 中无法识别关联关系。
- 必须显式写
<label for="user">用户名</label><input id="user" name="user"> -
for值必须与对应input的id完全一致（区分大小写、不可含空格） - 复选框/单选组要用同一个
name，但每个input必须有唯一id，每个都配独立<label for="xxx"></label>
form 元素的 method/enctype/action 要按场景锁定，不靠默认值赌运气
浏览器对 method 默认是 GET，但多数业务提交（如登录、注册、编辑）本质是状态变更操作，用 GET 会导致书签误触发、敏感参数暴露、URL 截断风险——这不是风格选择，是 HTTP 语义错误。
- 非幂等操作一律用
method="POST"；含文件上传必须加enctype="multipart/form-data" -
action不要留空：留空即提交到当前 URL，但 SPA 场景下当前 URL 可能带 hash 或 query，导致后端路由错乱 - 如果表单跨域或需 iframe 回调（如老式支付），明确写
target="iframe_name"，别指望浏览器猜
fieldset + legend 是分组刚需，不是“锦上添花”
没有 <fieldset></fieldset> 的地址表单，在 NVDA 或 TalkBack 中会被读作“城市输入框、省份输入框、邮编输入框”，完全丢失“这是送货地址”这一上下文。而 <legend></legend> 是唯一被无障碍 API 强制识别的分组标题语义节点。
- 所有逻辑分组（如账单地址/收货地址、偏好设置/通知方式）必须用
<fieldset></fieldset>包裹 -
<legend></legend>必须存在且文本有意义，不能写“分组1”或留空 - 禁用整组时，直接给
<fieldset disabled></fieldset>，比遍历内部所有input更可靠
按钮类型必须用 button[type] 显式声明，别依赖 input[type]
<input type="submit"> 在 iOS Safari 中曾长期存在 focus 后键盘不弹出的问题，且无法内嵌 SVG 或换行文本；而 <button type="submit"></button> 是 W3C 推荐的现代方案，所有主流引擎对其语义和行为支持一致。
- 提交按钮统一用
<button type="submit">提交</button>，不要用<input type="submit"> - 重置按钮慎用：
<button type="reset"></button>会无差别清空所有字段初始值，包括动态生成的 hidden 字段——生产环境建议用 JS 手动控制重置逻辑 - 普通操作按钮必须写
type="button"，否则在表单内点击会意外触发表单提交（浏览器默认 behavior）
最常被跳过的细节是：表单内任何可交互元素（包括自定义组件）都必须参与 tab 顺序、支持 keyboard focus、响应 Enter 和 Space 键——这不靠 CSS 实现，靠 HTML 结构本身是否承载语义。写完表单，用键盘 tab 走一遍，卡住的地方就是规范没落地的位置。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
