type属性决定input的行为和语义，关乎数据类型处理、原生校验、键盘匹配及辅助技术识别；选错会导致验证失效、移动端键盘不匹配、后端收不到值等问题。
type 属性决定 <input> 的行为和语义，不是“看起来像什么”，而是“它该处理什么类型的数据”。选错 type 会导致移动端键盘不匹配、原生验证失效、辅助技术无法识别，甚至后端收不到值。
什么时候必须用 type="email" 而不是 type="text"
浏览器对 type="email" 有两级校验：输入时自动高亮非法格式（如缺 @），提交时阻断（除非加了 novalidate）。但注意：type="email" 不校验域名是否存在，也不强制要求顶级域是 .com；它只检查基本结构。如果你需要更严的邮箱格式（比如限制为公司域名），仍需配合 pattern 或 JS 验证。
- 移动端会弹出带 @ 和 . 键的软键盘，减少用户手动切换
- 若只写
type="text"+inputmode="email"，仅影响键盘，无任何校验能力 -
value为空或格式错误时，checkValidity()返回false，可直接用于表单控制流 - 不要依赖它防注入——后端仍需清洗和验证
type="number" 的 min/max/step 实际约束力很弱
type="number" 的 min、max、step 只在用户通过上下箭头或滑动调节时生效；用户仍可手动输入任意数字（包括小数、负数、科学计数法），甚至粘贴非法值。它的主要价值是提供 UI 提示和基础交互，不是数据守门员。
-
step="1"并不能阻止用户输入3.14，除非同时设step="any"或显式限定 - 空值、
" "、"abc"都会让valueAsNumber返回NaN，需主动判断 - 某些旧版 Safari 对
step支持不一致，建议在关键业务中用 JS 补充校验 - 如果只是想限制输入为整数，
type="number" step="1"比正则pattern="[0-9]+"更可靠，因后者无法阻止粘贴
type="date" 返回的字符串格式固定，别硬解析
type="date" 的 value 始终是 YYYY-MM-DD 格式的字符串（如 "2026-09-04"），与用户系统区域设置无关。你不需要用 toLocaleDateString() 或正则拆分年月日——直接切分即可。
立即学习“前端免费学习笔记（深入）”；
- 不要用
new Date(input.value)构造日期对象再格式化，那会引入时区偏移风险 - 如果后端要求时间戳，用
Date.parse(input.value)（返回毫秒数）比new Date().getTime()更安全 - 用户未选择时，
value为空字符串""，不是null或undefined - 不支持 IE，若需兼容，必须降级为
type="text"+ 第三方日期控件
复选框和单选按钮的 name 是分组关键
type="checkbox" 和 type="radio" 的行为完全由 name 决定：相同 name 的 radio 互斥，相同 name 的 checkbox 才能被一起提交为数组（实际是多个同名键值对）。
- 漏写
name→ 提交时该控件完全被忽略（连空值都不会发） -
radio组里没设任何checked→ 提交时整个组不发送任何数据（不是发空字符串） - 后端收到同名多值（如
hobby=reading&hobby=gaming），需按多值方式解析，不是覆盖 - 不要用
id替代name控制分组逻辑，id只用于<label for>关联
最常被忽略的是：所有控件都依赖 name 才能进提交载荷，而 type 决定了这个值怎么生成、怎么校验、怎么被设备理解——它不是样式开关，是语义契约。
