移动端软键盘输入必须监听 input 事件并加防抖，因其唯一覆盖粘贴、语音、自动填充等所有场景；需配合 compositionend 处理未上屏输入，且 pattern 仅提交时校验，js 实时验证+setcustomvalidity() 才可靠。
移动端软键盘输入为什么不能只靠 blur
用户点完软键盘「完成」或「搜索」后，blur 在 iOS Safari 和部分 Android WebView 中经常不触发——尤其是页面滚动、键盘收起过快、或输入法未上屏时。你监听了 blur 却没收到事件，校验就彻底漏掉。这不是 bug，是软键盘生命周期和浏览器焦点管理的固有差异。
更麻烦的是，用户可能长按粘贴、语音输入、自动填充，这些操作都不会触发 keyup 或 change，但一定会触发 input。所以真实可用的起点只有一个：input 事件。
-
input是唯一能覆盖粘贴、语音、自动填充、手输所有场景的事件 -
change只在失焦时触发，移动端“失焦”不可靠，不能当主链路 -
keydown/keyup对粘贴无效，且软键盘回车键行为不统一（Android 是「搜索」，iOS 是「前往」） - 别依赖
focusout：它比blur更不稳定，且兼容性差
input 事件必须加防抖，否则 UI 会卡顿或错乱
用户每敲一个字就跑一次正则、发一次请求、调一次 setCustomValidity()，不仅浪费资源，还会因响应顺序错乱导致界面显示旧错误覆盖新正确状态。比如用户快速输入 “abc123”，中间发了三个请求，结果 “a” 的校验最后返回，就把 “abc123” 的成功状态给冲掉了。
防抖不是优化项，是必选项。标准做法是：
- 每次
input触发，先clearTimeout(timeoutId) - 再
timeoutId = setTimeout(() => validate(), 300)（200–400ms 区间最稳） - 务必把
timeoutId声明在闭包外或作为模块变量，否则无法清除 - 如果涉及 fetch，用
AbortController中断上一个 pending 请求，避免竞态
移动端 pattern + setCustomValidity() 联动要绕开两个坑
pattern 属性在移动端提交时才校验，且不支持 ^$，纯靠它做实时反馈等于没做。必须用 JS 的 test() 实时验证，并通过 setCustomValidity() 注入原生校验链。
但这里有两个高频翻车点：
- 没在每次
input后调用input.setCustomValidity("")：上次失败留下的错误不会自动清空，导致后续合法输入仍被拦 - 没对值做
.trim()：用户粘贴带空格的手机号或邮箱，test()直接返回false，但用户根本看不到提示（因为没调reportValidity()） - 别在
input里直接reportValidity()：它会强制弹出气泡，干扰输入节奏；只在blur或submit时调用 - 移动端 Safari 对
setCustomValidity()的气泡支持不一致，建议 fallback 到手动 DOM 提示（如加aria-invalid="true"+ 显示<span class="error"></span>）
真机验证比写代码还重要：别信模拟器的软键盘
Chrome DevTools 的设备模拟器对 inputmode、pattern、软键盘类型切换的支持严重失真。比如 inputmode="decimal" 在模拟器里弹出数字键盘，真机（尤其是 iOS 17+）可能还是全键盘。
真正有效的验证路径只有三条：
- 用真机连 Mac/Windows，通过 Safari Web Inspector 或 Chrome Remote Debugging 实时看事件流
- 在关键节点打
console.log：比如input是否触发、value.trim()长度、test()返回值 - 对高风险字段（如验证码、金额）加双重保险：
type="text"+inputmode="numeric"+pattern="[0-9]{4,6}"+ JS 实时test()
最常被忽略的是输入法未上屏状态：用户拼音输入“shouji”，还没按空格确认，DOM 值仍是“shouji”，但 input 事件已触发。这时做正则校验必然失败——得等 compositionend 事件后再校验，或者干脆跳过未完成输入。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
