真正能放心用、有实际意义的 input type 不超过 12 种：text、password、email、tel、url、search、number、range、date、datetime-local、month、week、color；其余如 datetime（已废弃）、time（Android WebView 支持差）、image（极少单独用）等行为不一致或仅实验性支持。
真正能放心用、有实际意义的 input type 不超过 12 种，其余不是行为不一致，就是已被废弃或仅实验性支持。
哪些 type 值现在能直接写进生产代码
截至 2026 年，Chrome / Firefox / Safari / Edge 都稳定支持且语义清晰的类型包括：
-
text、password、email、tel、url、search -
number、range、date、datetime-local、month、week、color -
checkbox、radio、file、submit、reset、button、hidden
注意：datetime（无 -local 后缀）已在 HTML5 中被移除，Safari 和 Chrome 早已不渲染；time 虽存在，但 Android WebView 支持极差；image 几乎没人单独用，output 根本不是 input 类型。
type="number" 的真实行为和常见误判
它不是“数字输入控件”，而是“带数字交互提示的文本框”：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 用户仍可粘贴
"123abc"或输入"1.2.3"，此时input.value可能为空字符串，input.valueAsNumber返回NaN -
step="0.01"在 Safari 中解析不稳定，Chrome 可能跳过0.3；建议整数场景用step="1"+inputmode="numeric" - 提交时值仍是字符串，后端不能假设已转为数字；金额类字段绝不能依赖它，
19.99可能变成19.990000000000002 - 移动端唤起数字键盘，但 iOS 允许输入
e和+，导致科学计数法混入
type="date" 的兼容性陷阱
桌面 Chrome/Firefox 显示原生日历，但 Safari 直到 v16.4 才完整支持 datetime-local，旧版只 fallback 为普通文本框；iOS Safari 虽显示日历，但 input.value 永远是 "YYYY-MM-DD" 字符串：
-
input.valueAsDate在 IE 完全不支持，Safari 旧版本也常返回null，必须降级用new Date(input.value)并校验有效性 - 默认值必须写成
value="2024-05-20"，写成"20-05-2024"或"May 20, 2024"会被浏览器忽略 - 安卓原生浏览器对
min/max属性限制常不生效，需用 JS 补充实时校验
type="search" 和 type="text" 的关键差异
不只是样式不同，底层语义和行为有实质性区别：
-
search默认带清除按钮（×），text没有 - iOS Safari 对
search触发搜索专用键盘（回车键标为“搜索”），text是通用键盘 -
search提交时两端空格自动 trim，text不会 - 某些旧 UA 下，空的
search字段可能被忽略不提交，而text总是提交空字符串 - 若你用 JS 实现自定义日期/颜色选择器，别强行套
type="date"或type="color"——它们会覆盖你的交互逻辑，统一用type="text"+role="textbox"更可控
最易被忽略的一点：所有这些 type 的价值都建立在「渐进增强」基础上。没有 JS 降级兜底的 date 或 number，在低版本 Safari 或某些国产 WebView 里，就是个裸 text 框——连 placeholder 都可能错位。别只看 MDN 文档里的“支持”，要看 caniuse 上具体版本的实测行为。
