inputmode 是软提示而非强制开关，兼容性差且受系统、浏览器、输入法等多因素影响；应按实际输入需求选值，避免与 type="number" 混用，并配合 pattern、oninput 等做校验和兜底。
加了 inputmode 却没弹出数字键盘，不是你写错了，而是它本就不保证生效——这个属性是软提示，不是开关，真机兼容性差才是常态。
inputmode 值该按输入内容选，而不是字段语义
别被“金额就该用 type="number"”带偏。实际要的是小数点？选 inputmode="decimal"；只要 0–9？选 inputmode="numeric"；要 *# 键？优先 inputmode="tel"。
-
inputmode="numeric"：只提供数字键，无小数点、无负号，适合验证码、手机号、页码 -
inputmode="decimal"：提示带小数点的键盘，但减号（−）不默认出现，别指望它支持负数输入 -
inputmode="tel"和inputmode="email"是目前最稳的两个值，在 iOS 16.4+ 和 Android Chrome 82+ 上行为较一致 -
inputmode="search"不改键盘布局，但能把回车键文字统一为「搜索」，且event.key === 'Enter'可靠 -
inputmode="url"、inputmode="none"、inputmode="verbatim"效果极不稳定，慎用
type 属性会压制 inputmode，必须搭配正确
inputmode 只在 type="text"、type="search"、type="email"、type="tel"、type="url" 或 textarea 上大概率生效；一旦混用 type="number"，iOS 直接忽略 inputmode，Chrome 行为也不一致，还可能触发微调按钮、禁粘贴、小数点转逗号等副作用。
- 验证码 →
<input type="text" inputmode="numeric" pattern="[0-9]{4,6}"> - 金额输入 →
<input type="text" inputmode="decimal" pattern="[0-9.]*">，再用parseFloat()处理值 - 邮箱输入 →
<input type="email" inputmode="email">，语义和提示双保险 - 别写
<input type="number" inputmode="decimal">，白写还埋坑
真机测试比模拟器可靠十倍，尤其要覆盖国产机型
Chrome DevTools 模拟器显示“数字键已出现”，不代表用户手里的 OPPO Find X7 能看到；小米弹数字键、vivo 弹拼音、华为 fallback 到全键盘，都是正常现象。
- iOS Safari 直到 16.4 才开始支持
inputmode，旧系统直接忽略 - vivo、华为、OPPO 系统输入法（如 Jovi、HMS、iFlyIME）基本不读取
inputmode，只响应type="tel"或type="number" - 中文输入法激活时，
inputmode="email"的 @ 键、inputmode="decimal"的小数点都会消失，这是系统级限制，前端拦不住 - 长按粘贴 “+86 138****1234” 或 “12.5%” 依然能进输入框——
inputmode从不拦截内容
inputmode 不解决任何校验、遮挡或容错问题
它只是个键盘“导购员”，指路可以，不管用户最后买不买东西。所有过滤、格式化、长度控制、错误提示，都得靠你自己补上。
- 用
pattern限制输入字符范围，比如pattern="[0-9.]*" - 用
oninput实时清理非法字符，比如oninput="this.value = this.value.replace(/[^0-9.]/g, '')" - 用
onblur或提交前做正则校验，不能只信键盘提示 - 键盘遮挡？监听
focus后调用scrollIntoView()，和inputmode无关 -
inputmode="none"不禁用输入，只藏键盘——适合自建软键盘场景，普通表单慎用
真正容易被忽略的点是：你写的 inputmode 值，从来不是最终决定键盘行为的唯一变量；系统版本、浏览器内核、输入法实现、父容器样式（比如 transform 或 position: fixed），任何一个都可能让它失效。写对了只是起点，后面所有校验和兜底逻辑，一个都不能少。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
