type="email" 触发浏览器原生校验并优化键盘，但不验证真实性；label for 语义化聚焦，onclick focus 破坏可访问性；radio 依赖 name 实现互斥；date 在 webview 中常降级，需 fallback；name 与 id 必须严格配对才能正确提交数据。
input type="text" 和 type="email" 的区别在哪
别只看表单控件长得像，type="text" 是万能兜底，type="email" 会触发浏览器原生校验：提交时自动检查格式（含 @ 符号和域名部分），iOS 键盘还会默认弹出 @ 键。但注意，它不验证邮箱是否真实存在，也不阻止用户绕过校验直接提交。
实际建议：
- 邮箱字段优先用
type="email"，配合required属性增强提示 - 不要依赖前端校验做安全判断，后端必须重验
- 如果字段是“备用邮箱”或可为空，去掉
required，但保留type="email"提升输入体验
label for 和 onclick 绑定点击聚焦的区别
label 的 for 属性是语义化标准做法，点击文字就能聚焦对应 input；而用 onclick 手动调用 focus() 是 hack 行为，破坏可访问性（屏幕阅读器无法识别），且在部分 Android 浏览器中可能失效。
关键点：
-
for值必须严格等于input的id，大小写、空格、下划线都不能错 - 避免把
label和input包在同一层div里再用for—— 这种嵌套不改变绑定逻辑，但容易误以为可以省略id - 如果用了
input的name而非id，for就完全失效
radio 单选组 name 属性为什么不能漏
浏览器靠 name 把多个 input type="radio" 归为一组，只有同名才能互斥选择。漏掉或写错 name，结果就是：看起来是单选，实际能同时勾选多个。
常见陷阱：
- 复制粘贴时没改新选项的
name，导致两组单选混在一起 - 用中文或带空格的字符串当
name值，部分旧浏览器解析异常 -
checked属性只控制初始状态，不影响分组逻辑 —— 分组全靠name
移动端日期选择器为什么有时不生效
input type="date" 在 iOS Safari 和多数安卓 Chrome 上表现良好，但在微信内置浏览器、QQ 浏览器等 WebView 环境里常被降级为普通文本框，不弹出日期面板。
应对方式：
- 始终搭配
placeholder="YYYY-MM-DD"，给用户明确格式提示 - 用 JavaScript 检测
input.type === "date"是否被支持，不支持时 fallback 到第三方 picker（如 flatpickr） - 服务端接收时别假设格式一定正确，仍需按规则解析并校验范围（比如出生日期不能大于今天）
最易被忽略的是 name 和 id 的配对关系——它们不是可选优化项，而是表单数据能正确提交的硬性前提。少一个字符，就可能让整行数据丢在前端。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
