2026年主流浏览器中，仅email、url、number、date、datetime-local、month、week、time触发原生验证；tel和search不校验格式，仅影响键盘与样式；动态改type会清空状态，日期类value须严格ISO格式。
别直接查 MDN 或 W3C 列表——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会被接受但显示为空） -
tel和search：**完全不校验格式**，仅影响键盘和 UA 样式
移动端键盘适配靠 type，不是靠 JS
iOS 和 Android 原生根据 type 切换软键盘布局，这是 HTML 层能力，JS 无法模拟：
-
type="tel"→ 数字键盘（含*#），适合国内手机号；别用number，它会吞掉开头的0，且长数字可能显示为科学计数法 -
type="email"→ 键盘带@和.com快捷键；加inputmode="text"会覆盖此行为，失去快捷键 -
type="url"→ 键盘带/和.com；若强制要求 HTTPS，得用pattern="^https?://.+" -
type="search"→ iOS 自带清空按钮（×），部分安卓键盘加搜索图标；type="text"没这个效果
动态修改 type 会导致 value 失效
input.type = "number" 这类赋值看似简单，但实际会重置控件内部状态：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
valueAsNumber、valueAsDate等属性在type切换后立即失效，返回NaN或null - 原
value字符串仍保留在 DOM 中，但控件 UI 可能清空（尤其日期类），造成“值丢了”的错觉 - 正确做法是：用
display: none+visibility: hidden切换不同type的 input 元素，而非复用同一个元素 - 例如手机号输入场景，不要在
text和number之间切换，而应准备两个 input，按需显隐
日期类 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"或"YYYY-MM-DDThh:mm:ss"（T不可省略） -
time：仅时间部分，"HH:MM"或"HH:MM:SS"，24 小时制（"11:54 AM"❌） - 格式错误时，控件 UI 显示为空，但
input.value仍返回你设的错误字符串——容易误判为空值
最常被忽略的是：日期类控件在 Safari 中对 datetime（UTC）基本不支持，但 datetime-local 可用；而 Firefox 对 week 的 min/max 解析存在偏差。这类兼容性问题没法靠“加 polyfill”彻底解决，得靠服务端兜底或降级为 text + 自定义日历组件。
