inputmode仅建议键盘布局，无法解决负数、百分比、科学计数法、带单位数值等复杂格式引导问题，必须配合type="text"+显式校验+用户反馈闭环兜底。
inputmode 不解决复杂输入格式的引导问题，它只向输入法“建议”键盘布局，对格式校验、粘贴容错、多语言混合、负数/科学计数法/带单位数值等场景完全无干预能力。真正在意输入格式的字段，必须放弃靠 inputmode “引导”的幻想，转而用 type="text" + 显式校验 + 用户反馈闭环来兜底。
为什么 inputmode="decimal" 无法支持负数或百分比
多数软键盘（尤其 iOS 系统键盘）默认不提供减号（-）或百分号（%）键，即使你写了 inputmode="decimal"，用户仍需手动切出全键盘才能输入。这不是 bug，是设计使然：inputmode 的语义仅限“小数点 + 数字”，不扩展符号集。
-
inputmode="decimal"在 Android Chrome 上可能显示小数点和逗号，但减号需长按数字键才出现，且位置不固定 - iOS 键盘在中文输入法激活时，
inputmode全部失效；切回英文后，减号也不在默认布局中 - 用户粘贴
-12.5%或3.14e-2依然能成功，inputmode从不拦截内容 - 真正要支持负数+小数，得用
pattern="-?[0-9.]*"+oninput过滤 + 提交前parseFloat()或Number()校验
inputmode 和 type="number" 混用是典型踩坑点
写 <input type="number" inputmode="decimal"> 几乎等于白写：iOS 直接忽略 inputmode，Chrome 行为不一致，部分机型还会触发微调按钮、禁用粘贴、把小数点转成逗号（受系统区域设置影响），导致 12.5 变成 12,5。
- 金额、评分、温度等含小数的字段，应统一用
<input type="text" inputmode="decimal"> - 搭配
pattern="[0-9.]*"防止非预期字符，再用oninput="this.value = this.value.replace(/[^0-9.]/g, '')"实时清理 - 提交时用
parseFloat(value)转换，isNaN()判空或非法，比依赖type="number"的原生验证更可控 - 若必须用
type="number"（如需上下箭头），务必加step="any"并监听input事件做格式归一化
带单位、多段式、混合格式字段别碰 inputmode
像“180cm”、“+86 138****1234”、“2026-09-04”、“192.168.1.1”这类字段，inputmode 完全不适用。它没有“带空格的数字”“带横线的日期”“带星号的手机号”等取值，所有尝试（如 inputmode="tel" 配合带空格号码）都只是碰运气。
- 手机号带区号或空格 → 用
<input type="tel">+pattern="[\d\s+\-\(\)]*"+onblur格式化 - IP 地址 → 放弃键盘引导，用
<input type="text">+ 分段input或自定义组件，inputmode对四段点分毫无帮助 - 日期/时间 → 优先用
<input type="date">/<input type="datetime-local">，它们才是真有语义和控件的方案 - 带单位数值（如“50kg”“2.5L”）→ 必须拆成数字输入框 + 单位下拉，或用
contenteditable+ 自定义解析，inputmode无对应值
最常被忽略的事实是：inputmode 的存在本身，就假设用户会“主动配合键盘提示去输入”。但现实中，用户更习惯粘贴、长按、切输入法、手输空格和符号——这些行为它一律不管。所谓“优化”，只是减少一次键盘切换；而真正影响体验的，是后续所有校验是否及时、错误提示是否明确、格式化是否自然。别把 inputmode 当成输入控制的起点，它只是个微弱的、不可靠的、需要大量补救的信号。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
