inputmode="decimal" 是移动端唤起纯数字键盘最稳的选择，iOS和Android主流浏览器均支持，不显示负号、e等符号，适用于验证码等场景，但需配合oninput清洗非法输入。
inputmode="decimal" 是移动端唤起纯数字键盘最稳的选择
想让手机弹出不带符号的数字键盘，inputmode="decimal" 比 type="number" 更可靠。iOS 和 Android 主流浏览器都支持它，且默认不显示负号、e、+ 等科学计数法字符——这正是多数业务（如验证码、订单号、身份证后四位）真正需要的输入体验。
注意：inputmode 只是提示浏览器“你该用什么键盘”，它本身不校验内容、不阻止粘贴、也不影响 value 类型。它只是个语义信号，别指望靠它拦住非法输入。
-
inputmode="numeric"在部分 iOS 版本 fallback 到decimal，Android 上更倾向纯数字键位，但兼容性略低，不建议首选 -
inputmode="tel"虽然也常弹数字键盘，但语义是电话号码，键盘上方可能带符号行（#+=），辅助技术会误读，且允许空格、括号等，不该滥用 -
inputmode对type="number"无效——两者混用时，浏览器优先按type解析，inputmode被忽略
为什么只设 inputmode 还不够？必须配 oninput 清洗
哪怕键盘只弹数字，用户仍可通过粘贴、语音输入、拖拽等方式塞进非数字字符（比如粘贴“123abc”或语音识别成“一二三”）。inputmode 完全不干预这些行为。
所以必须监听 input 事件，用正则实时清理：
立即学习“前端免费学习笔记（深入）”；
oninput="this.value = this.value.replace(/[^0-9]/g, '')"
这个正则比 /[^\d]/g 更安全：\d 在某些环境会匹配 Unicode 数字（如阿拉伯数字），而 [^0-9] 明确只放行 ASCII 0–9，避免意外。
- 不要用
keydown：它捕获不到粘贴、语音、剪贴板历史等输入方式 - 别信
pattern="[0-9]*"：它只在reportValidity()或表单提交时起作用，对输入过程零约束 - 如果需支持小数点，正则要升级为
/[^0-9.]/g，但得额外处理多个点、开头/结尾点等边界，复杂度陡增
type="text" + inputmode 是当前最可控的组合
直接放弃 type="number"，改用 type="text" 配合 inputmode="decimal" 和 oninput 清洗，是目前唯一能兼顾体验、语义和控制力的做法。
type="number" 的设计目标是“数值”，不是“纯数字字符串”。它合法接受 -123、1.5e2、.7，这是规范行为，不是 bug。想拦负号或小数点，硬靠 min="0" 或 step="1" 没用——它们对非法字符串不生效，对已输入的负号也无反应。
-
type="text"让 value 始终为字符串，避免valueAsNumber返回NaN带来的类型混乱 - 去掉
type="number"后，自动消失的上下箭头和科学计数法支持，反而是干净输入的必要代价 - 若担心无障碍支持，可加
aria-label明确说明用途，比如aria-label="请输入6位验证码"
服务端永远要重校验，前端清洗只是体验优化
所有前端过滤（oninput、pattern、checkValidity）都可被绕过。用户禁用 JS、用 curl 提交、或调试工具改 DOM，都能把 "12a3" 直接送过来。
所以服务端收到字段后，必须用相同逻辑再跑一遍 /[^0-9]/g 清洗，再转成数字或校验长度。这不是“以防万一”，而是必选项。
容易被忽略的一点：移动端键盘切换频繁，用户可能在数字键盘上按两次「切换」键调出字母键盘，然后输一串字母——这种操作不会触发任何前端拦截，只靠 inputmode 和 oninput 也拦不住，最终依赖服务端兜底。
