pattern属性无法可靠验证国际电话号码，必须用javascript结合libphonenumber库实现动态解析与校验，并在服务端用同源库二次验证。
pattern 属性对国际电话号码基本无效
直接用 pattern 验证国际电话号码几乎必然失败。HTML5 的 pattern 仅在提交时触发，且只支持正则（无 Unicode 属性、不支持多语言数字），更关键的是：它无法区分 +86 138-1234-5678、0086 138 1234 5678、(+86) 138.1234.5678 这类合法变体——所有这些都该被接受，但 pattern 只能匹配一种固定格式。
常见错误现象：pattern="^\+\d{1,4}\s?\d{10,15}$" 看似合理，实际漏掉法国 +33 1 23 45 67 89（空格分隔）、日本 +81 3-1234-5678（短横）、巴西 +55 (11) 91234-5678（括号+短横）等真实格式；更糟的是，它会把用户输入的 +86 138 1234 5678（带空格）直接标为无效，而这是完全合规的输入。
真正可用的验证必须脱离 pattern，靠 JavaScript + libphonenumber
libphonenumber（Google 开源库）是事实标准，它能解析、格式化、验证任意国家的号码，且自带地区规则更新。浏览器端可用轻量版 libphonenumber-js，npm 安装后导入即可：
import { parsePhoneNumberFromString } from 'libphonenumber-js'
验证逻辑应放在 input 或 blur 事件中，而非依赖表单原生提交：
- 用户输入后立即调用
parsePhoneNumberFromString(inputValue, defaultCountry)，其中defaultCountry是可选的国家码（如'CN'），用于补全无国家前缀的号码 - 检查
phoneNumber.isValid()，而非phoneNumber.isPossible()（后者仅校验长度，不保证真实存在） - 若有效，用
phoneNumber.formatInternational()标准化显示（如转成+86 138 1234 5678），并存入隐藏字段供后端使用 - 若无效，显示具体错误（如
"号码格式不正确，例如：+86 138 1234 5678"），而不是笼统的“格式错误”
表单中仍需保留 pattern，但仅作基础兜底和 UX 提示
pattern 在这里不是验证主力，而是辅助性提示：防止用户输入明显非法字符（如字母、中文括号），并触发浏览器原生 tooltip 提示。建议设为宽松正则：
<input type="tel" pattern="[+\d\s\-\(\)]*" title="请输入国际电话号码，例如：+86 138 1234 5678">
这个 pattern 不做严格校验，只过滤掉 abc、邮箱@domain 这类明显错误；title 提供示例，降低用户首次输入门槛。注意：type="tel" 在移动端会唤起数字键盘，比 text 更友好。
服务端必须重复验证，且不能信任前端任何结果
前端 libphonenumber 验证只是用户体验优化，服务端必须用同源库（如 Node.js 的 awesome-phonenumber 或 Python 的 phonenumbers）重新解析和校验。原因有三：
- 用户可禁用 JS 或绕过前端逻辑，直接 POST 原始字符串
- 前端库版本可能滞后，新号段未及时更新（如某国新增 10 位号段，旧版库误判为无效）
- 国际化号码常涉及运营商级规则（如印度部分号段仅限预付费用户），仅靠基础格式验证不够
服务端验证后，应存储标准化格式（phoneNumber.formatE164()），即去掉空格、短横，统一为 +8613812345678，便于后续短信网关调用或去重。
真正麻烦的地方在于：不同国家的“有效号码”定义本身就在变——尼日利亚去年新增了 11 位移动号段，越南今年调整了固话区号位数。验证方案必须能快速同步规则更新，而不是写死正则或硬编码长度判断。
