2026年主流浏览器中，仅email、url、number、date、datetime-local、month、week、time触发原生验证；tel和search不校验格式，仅影响键盘与样式；动态改type会清空状态，日期类value须严格iso格式。
别查 MDN 列表式文档——type 不是“有多少写多少”，而是“哪些真有用、哪些会踩坑”。2026 年主流浏览器（Chrome 124+、Firefox 125+、Safari 19.4+）对 input 的 type 支持已收敛，但语义误用、动态切换、移动端键盘错配仍是高频问题。
哪些 type 会触发原生验证？
只有明确语义且被广泛实现的类型，在 form.submit() 或调用 input.reportValidity() 时才校验格式：
-
email：要求含@且前后至少一个字符（u@x合法，@单独不合法）；不校验域名是否存在 -
url：允许无协议（example.com通过），但若带https://必须格式完整；foo不通过 -
number：仅检查是否可解析为数字（12e3合法，12.3.4不合法）；valueAsNumber对非法值返回NaN -
date、datetime-local、month、week、time：只校验 ISO 格式字符串，不校验日期逻辑（2026-02-30会被接受但 UI 显示为空） -
tel和search：完全不校验格式，仅影响软键盘布局与 UA 样式
type="tel" 为什么比 type="number" 更适合手机号？
这不是“看起来像不像”的问题，而是底层行为差异：
-
type="tel"唤起数字键盘（含*#），适配国内号码习惯；屏幕阅读器识别为电话字段，提升可访问性 -
type="number"会吞掉开头的0（如021-12345678变成2112345678），Android Chrome 对长数字可能显示为科学计数法 - 若需轻量格式提示，配合
pattern="[0-9*#+\s]{5,20}"；强制纯数字需额外加oninput="this.value=this.value.replace(/\D/g,'')"，但这只是兜底，非type本职
动态修改 input.type 为什么值“丢了”？
赋值如 el.type = "number" 看似简单，实则重置控件内部状态：
-
valueAsNumber、valueAsDate等属性立即失效，返回NaN或null - 原始字符串仍保留在 DOM 的
value属性中，但 UI 可能清空（尤其日期类），造成“值消失”错觉 - 正确做法是用
display: none+visibility: hidden切换不同type的input元素，而非复用同一个元素 - 例如手机号场景，应准备两个
input（type="text"和type="tel"），按需显隐
日期类 type 的 value 为什么必须严格 ISO？
浏览器不会帮你转换，所有日期相关 type 的 value、min、max 都只认 ISO 8601 字符串：
-
date：必须为"YYYY-MM-DD"（"2026-04-30"✅，"30/04/2026"❌，"2026-4-30"❌） -
datetime-local：格式为"YYYY-MM-DDTHH:mm"（不含秒或时区） -
month：必须为"YYYY-MM"；week：必须为"YYYY-Www"（如"2026-W25"） - 后端传来的非 ISO 时间字符串（如
"2026/04/30"）必须前端转格式，否则控件不渲染或设为空
真正容易被忽略的不是“怎么写”，而是“什么时候不该用”——比如用 type="number" 接收带前导零的编号、用 type="email" 代替后端邮箱校验、在日期控件里直接塞非 ISO 字符串。这些坑不报错，但会在用户侧静默失效。
