仅用 不足以实现可靠电话输入，因浏览器行为差异大、无格式校验、移动端键盘触发不稳定；需配合 inputmode="tel"、合理 pattern 与 title，前端轻量过滤+后端深度校验（如 libphonenumber-js），且服务端必须二次校验。
直接用 <input type="tel"> 就能实现基础电话输入框，但真要兼顾体验、校验和兼容性，光靠 type 属性远远不够。
为什么 type="tel" 不能只靠它自己
浏览器对 type="tel" 的处理差异很大：iOS Safari 会弹出数字键盘，Chrome 桌面版几乎不干预，Android 厂商键盘行为也不统一。更关键的是，它完全不校验格式——用户输“123abc”或留空都能通过 required。
- 它只是提示浏览器“这是电话”，不是约束输入内容
-
pattern属性必须配合title才能在提交时显示提示（否则失败静默） - 移动端软键盘触发依赖 UA 和系统，
inputmode="tel"比type="tel"更可靠
inputmode="tel" 和 type="tel" 要一起写
双保险写法才能最大限度唤起数字键盘，尤其在 Android 和新版 iOS 上：
<input type="tel" inputmode="tel" pattern="[0-9+\-\s()]{7,}" title="请输入有效电话号码（支持+、空格、括号、短横线）" required>
注意：inputmode 是 HTML5 属性，目前所有主流浏览器都已支持；pattern 的正则别太激进——比如强制要求 11 位纯数字，会把国际号码（+44 20 7946 0018）或分机号（123-456-7890 x123）全拦死。
前端实时格式化容易踩的坑
用户边输边加括号/空格（如 “138 1234 5678”），看似友好，实则埋雷：
- 光标位置错乱：插入字符后，光标常跳到末尾，破坏连续输入体验
- 粘贴失效：用户复制带空格的号码粘贴，格式化逻辑可能误删或重复处理
- 无障碍问题：屏幕阅读器可能读出“一三八 空格 一二三四……”，干扰理解
- 后端解析成本增加：你存了 “(138) 1234-5678”，但 API 要的是纯数字或标准 E.164 格式
更稳妥的做法是：前端只做轻量过滤（如删掉字母），格式化交给后端或展示层；若必须前端格式化，请用 beforeinput 事件 + setSelectionRange 手动维护光标。
真正需要校验时，别信 checkValidity() 就完事
form.checkValidity() 只跑 HTML 内置规则（required、pattern），无法覆盖业务逻辑，比如：
- 区号是否合法（国内手机号不能以 0 开头，且第二位不能是 0/1/2）
- 是否重复提交（防刷）
- 国际号码是否符合 E.164（+ 开头，总长 8–15 位数字）
建议在表单 submit 事件里，用 libphonenumber-js 这类库做深度验证——它能解析、格式化、校验全球号码，比手写正则靠谱得多。别省这点 bundle 体积，电话校验错一次，客服就多接一个投诉电话。
最常被忽略的一点：服务端永远要重新校验。前端一切控制都可绕过，电话字段又常用于登录、找回密码等关键路径，漏掉服务端校验等于裸奔。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
