手机号应使用type="tel"而非type="number"，因其可唤出带*#键的数字键盘、保留开头0且避免科学计数法显示，但不校验格式，需配合pattern或JS验证；email/url仅做轻量正则校验，后端必须二次验证；date/number存在兼容性陷阱，旧版Safari等会静默降级为text。
选错 type 不只是“看起来不一样”，而是直接导致软键盘弹错、校验绕过、移动端体验断裂，甚至后端收不到完整数据。
手机号该用 type="tel" 而不是 type="number"
很多人用 type="number" 接手机号，结果 iOS/Android 把开头的 0 吞掉，长号（如 138****1234）在 Android Chrome 里显示成科学计数法。而 type="tel" 会唤出带 * 和 # 的数字键盘，屏幕阅读器也能正确识别语义。
- 必须配合
pattern做轻量格式提示，比如pattern="[0-9*#+\s]{5,20}" - 别指望
type="tel"拦住字母——它本就不校验内容，只负责输入体验和可访问性 - 若真要强制纯数字+禁粘贴，得加
oninput="this.value=this.value.replace(/\D/g,'')"，但这属于兜底，不是type的职责
type="email" 和 type="url" 的校验边界在哪
它们触发的是浏览器内置正则：type="email" 只要求含 @ 且前后有字符（u@x 合法），type="url" 允许无协议（google.com 通过），但写成 https:// 开头就必须格式完整。
-
type="email"不校验域名是否存在，也不检查 TLD，后端必须二次验证 - 若要强制 HTTPS，不能只靠
type="url"，得加pattern="^https?://.+" - 别给
type="email"加inputmode="text"——这会覆盖默认邮箱键盘，失去@和.com快捷键
type="date" 和 type="number" 的兼容性陷阱
这两个类型在旧版 Safari、部分国产安卓 WebView 中根本没原生控件，直接退化成普通文本框，且 valueAsNumber 等 API 在动态改 type 时会失效。
立即学习“前端免费学习笔记（深入）”；
-
type="date"返回格式固定为YYYY-MM-DD，但 IE 完全不支持，需降级为type="text"+ 第三方日历库 -
type="number"的上下微调按钮在 Firefox 默认隐藏，Safari 对min/max支持不稳定 - 动态切换
type（比如从text改成date）会导致当前value清空或解析异常，应避免
真正难的不是记住每个 type 的名字，而是判断：这个字段在 iOS 键盘上该弹什么、是否需要语义支持、后端能否信任前端校验、老系统有没有 fallback 方案——这些才是选型时绕不开的点。
