HTML表单虽无官方结构规范，但必须显式设置action和method才能可靠提交；label须通过for/id绑定或嵌套input以保障可访问性；required和type="email"仅作前端提示，不可替代服务端校验。
HTML 表单没有所谓“官方结构规范”，但存在被广泛验证、浏览器原生支持、可访问性达标且利于维护的结构实践。偏离这些实践，轻则表单不可用，重则数据丢失、无障碍失效、移动端键盘错乱。
form 标签必须带 action 和 method 吗？
不是必须，但不设 action 会导致提交时页面刷新到当前 URL（可能 404）；不设 method 默认为 GET，这会让敏感数据（如密码）暴露在 URL 和服务器日志中。
- 登录/注册/修改类操作，一律用
method="post" - 搜索类简单查询，可用
method="get"，但需确认后端能正确解析 query string -
action值不能为空字符串或"#"，否则多数浏览器会提交到当前页，容易引发意外交互 - 若用 JS 拦截提交（如
event.preventDefault()），action可设为占位值（如action="#submit"），但别省略
label 和 input 的绑定为什么不能只靠位置相邻？
仅靠视觉对齐的 label + input 对屏幕阅读器无效，残障用户无法获知该输入框的用途，也无法通过点击 label 聚焦 input（部分浏览器会 fallback，但不可依赖）。
- 必须用
for属性绑定label与input的id：<label for="email">邮箱</label><input id="email" name="email"> - 或把
input包在label内（隐式绑定）：<label>邮箱<input name="email"></label>，但此时无法再用for，且不利于样式控制 - 没
id的input无法被显式label绑定，会直接导致可访问性失败
required 和 type="email" 这类原生校验靠谱吗？
它们提供基础防护和 UX 提升，但不能替代服务端校验，且行为在不同浏览器中略有差异（比如 Safari 对 type="email" 的正则比 Chrome 宽松）。
-
required只检查是否为空，不校验格式；type="email"仅做简单格式匹配（如含 @ 和 .），不验证域名是否存在 - 移动端会根据
type自动调起对应键盘（type="tel"→ 数字键盘，type="search"→ 带搜索图标的键盘），这是真实收益 - 不要仅靠
pattern实现复杂规则（如“密码需含大小写字母+数字”），它只触发浏览器提示，且正则写错会导致整个字段无法提交 - 原生校验的错误提示文案不可定制，中文环境常显示英文（如 “Please fill out this field”），需用
setCustomValidity()手动覆盖
表单提交后按钮禁用，为什么不能只加 disabled？
只设 disabled 会导致表单数据无法提交——因为 disabled 元素的值不会被包含在提交数据中，而提交按钮本身不需要传值，但它的 disabled 状态会阻止整个表单序列化。
- 正确做法是：提交瞬间设
button.disabled = true，同时确保form仍能正常收集并发送所有其他字段 - 更稳妥的方式是监听
submit事件，在event.preventDefault()后手动收集数据并用fetch提交，再禁用按钮 - 禁用后记得恢复（如请求失败时），否则用户无法重试；单纯靠页面刷新恢复不可靠（尤其 SPA 场景）
- 视觉反馈要同步：加 loading 动画、改文字为“提交中…”比单纯变灰更明确
真正难的不是写对一个 form，而是让每个 input 都有语义、可聚焦、可读、可验证、可恢复。这些细节堆叠起来，才是用户愿意填完、填对、再回来填的表单。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
