inputmode="decimal"仅优化数字键盘布局而非强制弹出，真机兼容性差是常态：ios 16.4前忽略，国产输入法多不支持，混用type="number"会失效；支付金额应选decimal，数量等整数用numeric；稳定写法为type="text"配合inputmode与js校验。
支付页面里加 inputmode 不是为了“确保弹出数字键盘”，而是为了在支持的机型上，把 0–9 键优先排到主区——它不拦截粘贴、不阻止中文输入、也不校验内容，真机兼容性差才是常态。
为什么支付金额输入框写了 inputmode="decimal" 还是弹全键盘
不是你写错了，是环境不认：iOS Safari 直到 16.4 才开始读这个属性，旧系统直接忽略；vivo Jovi、华为 HMS、OPPO iFlyIME 这类国产输入法基本不解析 inputmode，只响应 type="tel" 或 type="number"；更关键的是，一旦你混用 type="number"，iOS 会直接压制 inputmode，Chrome 行为也不一致，还可能触发微调按钮、禁粘贴、小数点转逗号等副作用。
常见错误组合：
-
<input type="number" inputmode="decimal">→ 白写，iOS 忽略后者 -
<input inputmode="decimal">（没写type）→ 浏览器按默认type="text"处理，但部分 Android WebView 可能降级为全键盘 -
<input type="text" inputmode="decimal" pattern="[0-9]*">→pattern写错，无法匹配小数点，提交时校验失败
inputmode="decimal" 和 inputmode="numeric" 在支付场景怎么选
看用户是否需要按小数点键，不是看字段叫“金额”还是“优惠券”。支付页常见字段的实际输入需求：
- 订单金额、实付金额、红包面额 → 用户要输
12.5、99.99，必须用inputmode="decimal" - 商品数量、优惠券编号、验证码 → 纯整数，比如
3、8888，该用inputmode="numeric"，多出小数点反而干扰 - 不支持负号：两个值都不默认提供减号（−），别指望用户能直接按出来；如需负数（如退款），得靠 JS 切换键盘或手动处理
别被“金额就该用 type="number"”带偏：type="number" 在 iOS 上小数点变逗号、长按粘贴失败、value 类型隐式转换，都是支付流程里的硬伤。
真正可控的支付输入框写法（含兜底）
核心原则：语义归 type，键盘归 inputmode，内容控制归 JS 和 pattern。以下组合经真机实测（iOS 16.4+、Android Chrome 82+、小米/华为主流机型）较稳定：
- 金额输入：
<input type="text" inputmode="decimal" pattern="[0-9.]*" autocomplete="off" oninput="this.value = this.value.replace(/[^0-9.]/g, '').replace(/(\..*)\./g, '$1')"> - 验证码或数量：
<input type="text" inputmode="numeric" pattern="[0-9]{4,6}" autocomplete="off"> - 手机号（收货/验证）：
<input type="tel" inputmode="tel">（双保险，type="tel"保自动填充和语义）
注意：oninput 正则不能简单删掉所有非数字字符——否则用户输 12. 时小数点会被立刻干掉，影响体验；要允许单个小数点存在，再在提交前用 parseFloat() 或正则二次校验。
最常被忽略的三点
第一，inputmode 对 contenteditable 无效，支付页如果用了富文本编辑器或自定义输入组件，加了也白加；第二，中文输入法激活时，inputmode="decimal" 的小数点键大概率消失，这是系统级限制，前端拦不住；第三，用户长按粘贴 "¥12.5" 或 "12.5%" 依然能进输入框——inputmode 从不干预内容本身，服务端永远要校验格式与范围。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
