^1[3-9]\d{9}$不再可靠，因漏掉19x号段、包含已停用物联网号段、不支持带分隔符或+86格式；应标准化去除非数字字符后查白名单校验。
PHP 验证手机号格式，不能只靠一个“万能正则”——国内号段持续更新，虚拟运营商、携号转网、19x 新号段都在变，^1[3-9]\d{9}$ 这类老正则已漏掉大量合法号码。
为什么 ^1[3-9]\d{9}$ 不再可靠
这个正则看似简洁，但问题明显：
- 匹配了已停用号段（如 140–144、146–149，现基本为物联网卡）
- 漏掉 19x 全系列（191、192、193、195、196、197、198、199），它们是工信部批准的正式公众号段
- 不区分虚拟运营商（170/171/172 等），而这些号段虽属虚拟运营，但号码本身完全合法可注册
- 无法识别“+86 13812345678”或“138-1234-5678”这类带分隔符的常见输入
推荐用 preg_match() + 宽松预处理 + 号段白名单
先标准化输入，再校验结构与号段。关键不是“拒绝一切异常”，而是“接受所有已知合法形式”：
- 用
preg_replace('/\D/', '', $phone)去除非数字字符（保留纯数字） - 若以
+86开头，截取后 11 位；若长度为 11 且以1开头，直接进入号段判断 - 号段白名单建议用数组而非长正则，便于维护。例如：
$valid_prefixes = [ '13', '14', '15', '17', '18', '19', '130','131','132','133','134','135','136','137','138','139', '145','147','149', '150','151','152','153','155','156','157','158','159', '170','171','172','173','175','176','177','178', '180','181','182','183','184','185','186','187','188','189', '191','192','193','195','196','197','198','199' ]; - 检查前 2 或前 3 位是否在白名单中（优先匹配 3 位，避免 170 被 17 截断误判）
注意 filter_var($phone, FILTER_VALIDATE_INT) 完全不适用
这个函数只校验是否为整数，对手机号毫无意义：
立即学习“PHP免费学习笔记（深入）”；
- 会把
"138abc12345"当作非法（正确），但也把"01381234567"（开头零）当作非法（错误——用户可能手误多输个 0，应先清理） - 对带
+、空格、括号的国际格式直接返回 false，而这些在表单中极其常见 - 它不关心位数、不校验号段、不处理前导零或国家码，纯属误用
真实场景要加一步：防机器批量提交
单纯格式校验只是第一关。生产环境必须配合：
- 前端 JS 做即时提示（减轻服务端压力），但不可依赖——JS 可被绕过
-
后端校验后，立即记录 IP + 手机号哈希（如
spl_hash('sha256', $phone)）用于频率限制 - 对同一手机号 1 小时内注册/登录超过 3 次，触发人机验证（如滑块）或短信验证码延迟下发
- 若需强一致性，最终仍应以运营商三要素（手机号 + 姓名 + 身份证）实名认证结果为准，格式校验只是前置守门员
号段白名单每年至少更新一次，别把它写死在 if 判断里；用配置文件或数据库表管理更稳妥。真正容易被忽略的，是“用户输入习惯”和“运营商实际放号节奏”之间的 gap——正则再准，也填不上业务逻辑和现实之间的那条缝。
