选inputmode="numeric"还是"decimal"看用户需按什么键：纯数字如验证码、手机号用"numeric"（仅0–9）；需小数点如金额、评分用"decimal"（含小数点，但无默认减号），且必须搭配type="text"和pattern校验。
inputmode="numeric" 和 inputmode="decimal" 到底该选哪个
看用户要按什么键，不是看字段叫“金额”还是“验证码”。inputmode="numeric" 只提供 0–9 数字键，无小数点、无负号，适合验证码、手机号、页码、商品 ID；inputmode="decimal" 提示键盘带小数点（部分 Android 还带逗号），但减号（−）不在默认布局里——别指望它支持负数输入。
常见错误：
-
inputmode="decimal"配验证码：小数点干扰输入，还可能被误粘贴进非法字符 -
inputmode="numeric"配金额：用户根本找不到小数点，输不了 12.5 - 写
inputmode="decimal"却没配pattern="[0-9.]*"或oninput清理逻辑：用户粘贴 “12.5%” 或 “abc123” 照样进框
为什么写了 inputmode 还是弹全键盘
这不是你代码写错了，而是典型兼容性失效现象。iOS Safari 直到 16.4 才开始支持 inputmode，旧系统直接忽略；vivo、华为、OPPO 等国产安卓输入法（如 Jovi、HMS）基本不读取该属性，只认 type="tel" 或 type="number"。
更关键的是：type="number" 会压制 inputmode：iOS 上直接忽略后者，Chrome 行为不稳定，甚至可能闪退。DevTools 模拟器显示“数字键已出现”，不代表真机行为一致——小米弹数字键，OPPO 弹拼音，非常常见。
真正起效的前提：
- 必须用
type="text"（或type="tel"/type="email"）配合inputmode - 不能用
type="number"混搭 - 必须在真机上测，尤其覆盖 iPhone（iOS 16.4+）和主流国产机型
type 和 inputmode 的组合怎么才稳
语义归 type，键盘提示归 inputmode，但两者有优先级。实测下来，这几组在多数真机上表现较一致：
- 手机号：
<input type="tel" inputmode="tel">——type="tel"保语义和自动填充，inputmode="tel"推动 *# 键优先 - 验证码：
<input type="text" inputmode="numeric" pattern="[0-9]{4,6}">—— 避开type="number"的粘贴拦截和微调按钮 - 金额输入：
<input type="text" inputmode="decimal" pattern="[0-9.]*">——type="text"避免 Safari 小数点转逗号，再靠parseFloat()处理值 - 邮箱：
<input type="email" inputmode="email">——inputmode="email"在 Android Chrome 上能提升 @ 和 . 快捷键出现率，iOS 基本无视但不冲突
以下组合基本无效：inputmode="number"（非标准值，浏览器忽略）、inputmode="url"（当前无主流输入法响应）、inputmode="text"（等同于不写）。
inputmode 不解决的三件事，必须手动补
inputmode 只是个键盘“导购员”，指路可以，不管用户最后买不买东西。它不拦截、不校验、不滚动：
- 不拦截粘贴：
"abc123"或"+86 138****1234"依然能进输入框，得靠pattern、oninput或提交前正则过滤 - 不解决键盘遮挡：聚焦后输入框被盖住？得监听
focus后调用scrollIntoView()，inputmode无能为力 - 不替代表单验证：它不控制
valueAsNumber、不触发checkValidity()、不改变required行为，所有业务校验逻辑都得自己写
最常被忽略的一点：中文输入法激活时，inputmode="decimal" 的小数点、inputmode="email" 的 @ 键都会消失——这是系统级限制，前端拦不住。你写的 inputmode 值再准，也管不了用户切到拼音后按什么键。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
