type="tel" 仅触发数字键盘和读屏语义，不校验格式；需用 pattern 或 JS 正则校验，配合 title 和 label 保障提示与无障碍；inputmode="numeric" 可增强键盘控制，但需兼容兜底；前后端均须独立清洗和验证国际号码。
type=tel 不会自动验证格式，别指望它拦住非法输入
浏览器对 type="tel" 几乎不做任何格式校验——输一串 abc123!@# 也能通过，checkValidity() 返回 true，表单照样能提交。它只是提示浏览器“这是电话场景”，触发手机键盘的数字布局、唤起通话快捷操作，仅此而已。
需要真正校验？必须手动加 pattern 属性或 JS 监听 input/blur 事件做正则判断。比如中国手机号常见写法：
<input type="tel" pattern="^1[3-9]\d{9}$" title="请输入有效的11位中国大陆手机号">-
pattern只在调用reportValidity()或表单 submit 时生效，用户不点提交就看不到提示 -
title是必填的配套项，否则 Chrome 等浏览器不显示 pattern 错误文案 - 别依赖
required+type="tel"当作格式约束——空值才触发 required 校验，非空乱码照收
移动端键盘行为差异大，iOS 和 Android 表现不一致
iOS Safari 的 type="tel" 会弹出纯数字键盘（带 * #），但默认不显示「拨号」按钮；Android 多数浏览器（Chrome、Firefox）也弹数字键盘，部分定制系统（如华为 EMUI）可能仍混入字母键。想强制数字键盘且带符号，可叠加 inputmode="numeric"：
<input type="tel" inputmode="numeric">
-
inputmode="numeric"比type="tel"更明确地告诉浏览器“只输数字”，但兼容性略低（iOS 12.2+、Android 7.0+） - 如果目标用户含旧版 iOS，建议保留
type="tel"作为兜底，再加inputmode提升新设备体验 - 避免同时写
inputmode="tel"——该值未被广泛支持，多数浏览器直接忽略
无障碍和语义化意义大于交互，screen reader 会读作“电话号码”
对于使用读屏软件的用户，type="tel" 能让辅助技术明确知道这是电话字段，朗读时会加上“电话号码”上下文，比 type="text" 更准确。但前提是必须配 label：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
<label for="phone">联系电话</label><br><input type="tel" id="phone">
- 没
label或仅用 placeholder，读屏软件大概率只读“编辑文本”，丢失语义 - 不要用
placeholder替代label，它不参与无障碍树，且在输入后消失 - 若需显示示例格式（如“138-1234-5678”），用
aria-describedby关联说明文字，而非塞进 placeholder
不要用 type=tel 做国际化号码处理，+86、括号、空格全靠自己清理
用户粘贴 +86 138 1234 5678 或输入 (010) 1234-5678 都合法——type="tel" 允许任意字符。后端收到的原始值很可能带空格、横线、加号、括号，直接入库或调用短信接口会失败。
- 前端建议在
blur时用正则清洗：value.replace(/[\s\-\(\)\+]/g, '')，再校验长度或前缀 - 服务端绝不能信任前端清洗结果，必须独立做国际号码解析（推荐
libphonenumber类库） - 显示回填时，别把清洗后的纯数字直接塞进 input——用户看到
13812345678会懵，应按本地习惯格式化后展示（如138-1234-5678），但提交仍用干净字符串
最常被忽略的一点：不同国家区号长度、号码总长差异极大，一个正则无法通吃所有场景。真要做国际化，type="tel" 只是起点，后面全是体力活。
