type="tel"最适合手机号输入，因其原生语义被iOS和Android Chrome识别为拨号键盘，支持*#键、不吞前导零、不转小数点，且兼容粘贴；而type="number"在iOS上会将小数点转为逗号、禁用长按粘贴、触发微调按钮，导致输入异常。
写 type="tel" 就能弹数字键盘，但写 type="number" 反而可能闪退或小数点变逗号——这不是 bug，是语义和系统行为的必然结果。
type="tel" 为什么比 type="number" 更适合手机号
移动端调用数字键盘最稳的方式，不是靠 inputmode，而是靠 type="tel" 的原生语义。iOS 和 Android Chrome 都会识别它并唤起带 *# 键的拨号键盘，且不干扰粘贴、不吞前导零、不强制转小数点。
-
type="number"在 iOS 上会把12.5显示成12,5（受系统区域设置影响），用户根本输不对 -
type="number"禁用长按粘贴，安卓上还可能触发微调按钮，遮挡输入框 -
type="tel"允许输入空格、括号、+、-，配合pattern="[0-9+\-\s()]{7,20}"做轻量提示即可，不硬拦 - 别给
type="tel"加inputmode="numeric"——多此一举，iOS 会忽略，安卓可能冲突
type="email" 和 type="url" 的键盘效果真实表现
type="email" 在 Android Chrome 上确实会在键盘顶部显示 @ 和 .com 快捷键；但在 iOS Safari（哪怕 16.4+）上基本没反应，尤其用户切到中文拼音后，@ 键直接消失——这是系统级限制，前端无法干预。
-
type="url"在 iOS 上会把空格键换成.和/，还有.com键；Android 基本无变化，微信 X5 内核完全无视 - 它们都只做基础格式校验：
u@x通过type="email"，example.com通过type="url"，不能替代正则 - 若需强校验，必须配
pattern或提交时 JS 处理，比如pattern="^[^\s@]+@[^\s@]+\.[^\s@]+$"
type="number" 在金额/评分场景下的实际陷阱
别用 type="number" 接收金额或带小数的字段。它在 iOS 上小数点被转逗号、粘贴失败、valueAsNumber 在动态修改 type 后失效——这些不是兼容性问题，是规范行为。
立即学习“前端免费学习笔记（深入）”；
- 正确做法是：
<input type="text" inputmode="decimal" pattern="[0-9.]*">，再用parseFloat()处理值 -
inputmode="decimal"不等于“支持负数”，减号不在多数软键盘默认布局里，用户得手动切键盘找 - 要支持负数或科学计数法？老实用
type="text"+oninput过滤 + 提交前正则校验 -
type="number"的min/max/step在移动端几乎无效，滑动 spinner 体验差，且 iOS 不渲染
真机测试必须覆盖的三个关键点
Chrome DevTools 模拟器里看到的键盘，和用户手里的手机完全是两回事。国产机型尤其不可信：vivo、华为、OPPO 的系统输入法对 inputmode 基本无视，只认 type="tel" 或 type="number"，但后者又自带一堆坑。
- 必测组合：
type="tel"在 iPhone（iOS 16.4+）和 vivo X100（OriginOS）、华为 Mate 60（HarmonyOS）上的键盘实际弹出形态 - 必测操作：长按粘贴
"+86 138****1234"或"12.5%"，看是否进框——inputmode从不拦截内容，这正常 - 如果某机型始终弹全键盘，立刻降级：手机号用
type="tel"，验证码用type="text" inputmode="numeric"，金额用type="text" inputmode="decimal"，别硬扛
真正容易被忽略的是：语义化 type 值本身不解决校验、不阻止粘贴、不处理键盘遮挡。你选对了 type，只是让键盘更友好；后面所有过滤、格式化、滚动定位、提交验证，还得一行行写。
