inputmode 属性用于提示浏览器预期输入类型以触发对应软键盘，仅影响键盘展示不校验内容；常见值包括 decimal、tel、email、search 等，需配合 pattern 和 js 校验确保数据合法性，且须真机测试兼容性。
input 元素的 inputmode 属性怎么用
直接控制输入法类型，靠的是 inputmode，不是 type 或 pattern。它告诉浏览器“用户接下来大概率要输什么”，从而触发对应软键盘（比如数字键盘、邮箱键盘）。但注意：它只是提示，不强制校验，也不影响提交逻辑。
常见错误是以为加了 inputmode="numeric" 就能拦住字母输入——不能。它只管键盘弹出类型，不管内容合法性。
-
inputmode="decimal"：适合金额输入（带小数点的数字键盘） -
inputmode="tel"：电话键盘，含 * # 号，但不会自动格式化或校验号码 -
inputmode="email"：部分安卓/Chrome 会显示 @ 和 .com 快捷键，iOS Safari 支持较弱 -
inputmode="search"：触发搜索键盘（带「搜索」回车键），比type="search"更轻量、无默认样式干扰
为什么 type="number" 不如 inputmode 可靠
type="number" 看似更“严格”，实际问题一堆：在 iOS 上常弹出数字键盘但允许粘贴字母；提交时自动转空字符串或 NaN；还可能触发讨厌的上下微调按钮（appearance: none 也难彻底干掉）。而 inputmode 只管键盘，不碰语义和校验，配合 pattern 和 JS 校验更可控。
典型翻车场景：用户想输 “12.5%” 或 “+86 138****1234”，type="number" 直接拒绝或截断，inputmode="decimal" + 自定义校验就能兼容。
立即学习“前端免费学习笔记（深入）”；
- 需要数值计算？用
inputmode="decimal"+pattern="[0-9.]*"+ JS parseFloat 安全校验 - 要兼容老浏览器？
inputmode不支持时降级为type="text"，不影响功能 - 别混用
type="number"和inputmode，行为可能冲突（比如 Chrome 中两者同时存在时优先级不明确）
移动端中文输入法下 inputmode 的真实表现
中文拼音输入法下，inputmode 主要影响「候选词栏上方的功能键」，而非是否允许打字。比如 inputmode="url" 会让键盘顶部出现 / .com 快捷键，但用户依然能切回拼音继续输汉字——它不锁输入法，只优化快捷入口。
容易被忽略的坑：iOS Safari 对 inputmode 支持滞后，inputmode="search" 在 iOS 16.4+ 才稳定生效，之前版本会回退到默认键盘。安卓各厂商差异更大，华为/小米键盘对 inputmode="tel" 响应积极，vivo 有时直接忽略。
- 测试真机比模拟器靠谱，特别是 iOS 实机
- 不要依赖
inputmode防错，该用pattern限格式、JS 做实时过滤就做 - 中文场景下，
inputmode="text"是安全兜底项，别强行用"none"（它不阻止输入，只隐藏键盘）
表单提交前如何补足 inputmode 没做的事
inputmode 解决不了数据清洗和业务校验。比如手机号字段设了 inputmode="tel"，用户仍可能粘贴 “138-1234-5678” 或 “+8613812345678”，这些得靠 JS 处理。
关键思路：把键盘体验和数据质量拆开管。一个负责“怎么输顺手”，一个负责“输完能不能用”。
- 监听
input事件，用正则实时过滤非法字符（如value.replace(/[^0-9+\-\s]/g, '')） - 提交前用
checkValidity()+ 自定义setCustomValidity()统一报错 - 避免在
keydown里拦截 keyCode，会破坏中文输入法的组合过程（比如按 shift+2 出 @，但被提前拦掉）
事情说清了就结束。最常被漏掉的其实是真机兼容性验证和中文输入法下的粘贴处理——这两块不测，上线后用户第一反应就是“键盘不对劲”或者“粘贴就崩”。
