1. 一串“魔鬼数字”到底在测什么半夜手机响屏幕上是一串几乎不像是号码的数字十个 9 排成一排。第一反应往往是“谁在恶作剧”第二反应是“这号码能拨通吗”。我做号码相关的业务系统有些年头了每次碰到这类截图关注点从来不是“吓不吓人”而是它把三个平时藏在系统底层的问题一次性摆到了台面上手机号校验规则到底有多松、特殊数字序列为什么总能穿过校验、风控面对这种输入到底该拦还是该放。这串“魔鬼数字”本身不神秘。它既不是某个地区的真实号段也不是什么隐藏彩蛋本质就是一段符合长度、但不符合真实号段分配规则的字符串。问题在于很多系统在校验时只做了“长度对不对”“是不是全数字”这两件事于是一串 9 就能大摇大摆走完注册、登录、短信下发、订单创建的全流程。等业务方发现异常往往已经是脏数据堆积、短信通道被刷、用户被骚扰之后了。这篇内容适合三类人看。第一类是正在写注册登录、表单校验的前后端开发者你需要知道校验要分几层、每层拦什么第二类是做过或正在做风控策略的同学你会看到单点规则为什么不够、组合策略怎么设计第三类是对接短信通道、做号码清洗的数据同学你能拿到一套可以直接抄的判定思路和排查表。全文围绕手机号校验、魔鬼数字、风控策略三个关键词展开不聊玄学只聊能落地的规则、参数和踩过的坑。需要先说明一点下文涉及的所有号码、号段、案例均为示意性描述用于说明校验逻辑不指向任何真实用户或真实事件。真实系统的号段数据应当以通信管理部门的公开分配文件为准定期更新这一点后面会专门讲。2. 手机号校验的四层结构从“像不像”到“是不是”2.1 第一层字符层先把“长得不像”的挡在门外字符层校验是最便宜的一道闸成本几乎为零却能被大量系统漏掉。它的职责很单纯判断这串输入在字符构成上有没有资格被当作号码。具体要拦的东西包括空值、首尾空格、全角数字、夹杂字母、夹杂横杠括号、Unicode 里那些长得像数字的字符比如某些语系里的数字符号以及各种零宽字符。这里有个很容易被忽略的点全角数字和半角数字在肉眼上几乎一样但在字符串比较里是两个世界。用户在中文输入法状态下敲出的“”如果直接入库后续所有基于半角规则的判断全部失效。我见过一个表单前端用正则卡了半角用户复制粘贴全角进去之后前端没拦住因为某些输入法会做自动转换后端也没做归一化结果这条数据在报表里显示正常、在检索时永远查不到。处理思路是先归一化再校验顺序不能反// 归一化全角转半角、去除空白与不可见字符 function normalize(raw) { if (typeof raw ! string) return ; return raw .replace(/[\uFF10-\uFF19]/g, ch String.fromCharCode(ch.charCodeAt(0) - 0xFEE0)) .replace(/[\u200B-\u200D\uFEFF]/g, ) .replace(/[\s\-()]/g, ); }归一化之后再做字符白名单判断只允许纯数字长度单独交给下一层。这样做的好处是归一的逻辑只写一次入库、比对、展示全部复用同一份结果避免“前端一套、后端一套、导出又一套”的三套规则打架。注意归一化会改变用户原始输入如果业务上有“保留原始输入用于审计”的需求要同时存原始值和归一化值两个字段别只留一个。字符层还有一个细节空字符串和 null 要区分处理。空字符串通常意味着用户提交了表单但没填属于业务校验失败null 往往意味着调用方漏传参数属于接口契约问题。这两种情况返回给前端的错误码和文案应该不一样否则排查线上问题时根本分不清是用户的问题还是调用方的问题。2.2 第二层结构层长度与格式的硬约束结构层管的是“形状”。国内手机号是11 位纯数字这是硬约束不多不少。很多系统的校验写成length 10 length 13这种宽松区间本意是兼容各类号码座机、境外号结果把 10 个 9 这种输入放进了主流程这就是标题里那串数字能进来的直接原因之一。宽松区间本身不是错错在没有分场景。同一个表单里可能同时存在“手机号”和“联系电话”两种语义前者必须严格 11 位后者可能允许座机、允许分机号、允许境外格式。做法是把校验器拆成两个校验器适用字段规则失败处理strictMobile注册、登录、短信下发、实名归一化后严格 11 位纯数字且首两位命中当前号段直接拒绝提示格式错误looseContact联系地址、备注、客服工单允许数字、横杠、括号、加号长度 5 到 20放行但标记为“非标准号码”进入人工复核队列表格里最右列是这套设计的关键。宽松校验不等于不校验而是要有一个“降级处理”的去处。很多系统的问题就在这儿要么全严把座机用户挡在门外要么全松把脏数据放进来。分成两条通道之后严格通道保持高门槛宽松通道把风险外溢到后置环节风险就变得可控、可观测。还有一个常被忽视的结构约束号码里不能出现连续过长或过度规律的重复。这里要小心重复判断本身很容易误伤比如某些真实号段天然带有重复特征。所以这条规则不能放在“格式校验”里直接拒绝而应该作为风险信号交给风控层打分这是后面第 4 节要展开的内容。格式层只做确定性判断概率性判断一律下移这条分界线我建议你划清楚。2.3 第三层号段层判断“这个号码理论上存在吗”长度对了、全是数字还不代表这个号码真实存在。号段的分配是有规则的前几位决定了它属于哪家运营方、属于哪类业务。校验的第三层就是拿号码前缀去比对一个定期更新的号段表。层的关键在于数据要活。号段会新增、会调整靠硬编码在代码里的常量迟早过期。我建议的形态是号段表独立存储可以是配置表、也可以是缓存里的一个集合应用启动时加载表结构至少包含前缀、位数、运营方标识、启用状态、生效时间、失效时间每次校验走缓存缓存有版本号配置变更后按版本失效避免全量刷新时的抖动保留一条“未知前缀”的兜底路径不至于因为号段表漏了一个新前缀就把正常用户全拒了。兜底路径怎么写直接决定系统的健壮性。我的做法是未知前缀默认放行但打标记允许完成注册同时给这条记录加上“号段未识别”的内部标签并降低该账号的初始信任分。这样既不误伤新号段的真实用户又给后续风控留了抓手。反过来“未知前缀直接拒绝”看起来很严实际上每逢号段更新就会引发一批客诉得不偿失。提示号段表一定要有更新机制和更新记录。出了问题第一件事是查“号段表最后一次更新是什么时候、谁改的、改了什么”没有这条记录排查会非常痛苦。2.4 第四层存在性校验成本最高必须最后做前三层都是本地判断第四层要花钱短信验证码、语音回拨、运营商三要素核验都是按次计费的。所以这一层的定位是最终确认绝对不能放在表单输入的实时校验里。这层最容易出的事故是顺序颠倒。我见过一个注册流程用户敲完第 11 位数字前端立刻调接口查号段、调接口发短信用户还在改最后一位短信已经发了三条。正确的做法是把发短信绑定在明确动作上点击“获取验证码”并且加上前端冷却和后端频控双保险前端冷却同页面同号码 60 秒内不可再次触发仅体验层可绕过 后端频控按号码 1 次/分钟、5 次/小时、10 次/天按来源IP 20 次/小时按设备指纹 10 次/小时 超限处理返回统一提示不区分是哪个维度命中避免被用来探测规则频控维度这里多说一句。只按号码限流是不够的攻击方换号就行只按 IP 限流也不够IP 池的成本很低。号码 IP 设备指纹三者的组合才是相对稳的结构任何一个维度超限都拦但对外返回的文案必须统一否则等于把规则白送出去。3. “魔鬼数字”为什么总能穿过校验五类典型漏洞3.1 漏洞一正则写宽了宽松成了默认值最常见的写法是^\d{6,15}$这类区间正则。作者的本意是“兼容各种号码”实际效果是任何 6 到 15 位的数字串都能过。10 个 9 正好 10 位稳稳落在区间里。这类正则的危险性在于它看起来很专业code review 时容易被放过。我的判断标准很简单凡是面向单一业务语义的字段注册手机号正则必须是精确的只有面向“备注、描述、补充联系方式”的开放字段才允许区间。同一个校验函数如果被两个语义不同的字段共用那就是隐患的源头。改法不是把正则收紧就完事而是拆函数。上面 2.2 里的 strictMobile 和 looseContact 就是这个思路。拆分之后严格通道的正则可以写成更精确的形式并且叠加号段判断10 个 9 在号段层就会被拦掉。3.2 漏洞二只做前端校验接口裸奔前端校验的定位是提升体验不是安全边界。绕过它只需要打开调试工具或者直接构造请求成本极低。我做过统计一个上线一段时间的产品如果只在表单上做校验接口层的异常号码占比通常在千分之几到百分之几之间具体取决于产品有没有被盯上。正确做法是同一份规则前后端各实现一次以后端为准。前端那份负责即时反馈后端那份负责最终裁决。为了避免两边规则漂移我的经验是把规则参数化长度、允许字符集、号段表版本全部放在配置里前后端读同一份配置前端在构建时注入后端运行时加载。规则要改就改配置不改代码漂移的概率会小很多。注意前端不要泄露过细的失败原因。“号码不存在”和“号码格式错误”这类细分提示在校验阶段应该合并成统一文案细分原因只写日志。原因很简单细分提示等于给探测者提供了一台免费的规则查询机。3.3 漏洞三批量导入接口漏掉了同一套校验这是我在实际系统里见过最多的一类问题。单个新增走的是严格校验批量导入走的是另一条代码路径而那条路径往往只做了“非空判断”。10 条也好10 万条也好全部原样入库。批量导入必须复用同一套校验器这一点没有讨论空间。工程上的做法是把校验抽成独立模块单条新增和批量导入都调它不允许任何一条路径自己写判断。批量场景还要额外加两条逐行返回结果成功多少、失败多少、失败行的行号和原因全部落库便于业务方修正后重传设置单次导入上限和总量阈值比如单次不超过 5 万行超过走异步任务异常率超过某个比例例如 30%时中止整批避免把一批脏数据一次性灌进去。3.4 漏洞四历史数据里的脏值影响了新逻辑老系统留下的数据往往带着历史宽松规则的痕迹。这些数据平时不显眼一旦做号码相关的功能迭代就会冒出来号码补全、号码去重、按号码关联账号全都会踩。处理历史脏数据要有节奏。第一步是盘点按规则跑一遍全量统计各类异常的数量和分布先做到心里有数第二步是隔离把异常记录打标不参与依赖号码的关键流程比如不用于账号合并、不用于营销触达第三步才是清洗能补全的补全补不了的保持标记状态别强行改。强行把 10 个 9 改成某个真实号码是最糟糕的处理方式。表格形式的盘点结果是我每次做这类治理时必交的东西异常类型判定规则预估占比处置动作长度异常归一化后位数不等于目标位数待统计打标不参与关键流程全同数字所有字符相同待统计打标进入人工复核顺序列连续递增或递减如 12345678待统计打标进入人工复核号段未识别前缀不在当前号段表待统计打标降低初始信任分明显伪造常见占位模式全 0、全 9 等待统计打标禁止用于触达3.5 漏洞五异常输入直接进了下游放大成事故这一条是前面几条的后果但值得单独拎出来说。一个异常号码本身不可怕可怕的是它进了短信通道、进了营销名单、进了外呼任务。短信通道被刷是直接的钱营销触达异常号码可能引发投诉外呼任务里的假号码会白白消耗坐席时间。防的手段是在下游入口加一道号码质量闸。任何批量触达任务在创建时先按上面的判定规则过滤一遍把异常号码剔出来单独处理不混在正常任务里执行。这道闸的成本很低收益是把事故挡在花钱之前。4. 风控策略怎么搭从单点规则到分层打分4.1 为什么单点规则一定会失效单点规则的特点是“一刀切”命中就拦不命中就放。它的问题不在于不严而在于无法表达程度。10 个 9 明显异常一个正常的 11 位号码也可能因为用户手滑少敲一位两者在单点规则下要么都被拦、要么都被放没有中间态。风控要解决的是这个“中间态”所以结构上必须是分层 打分。分层解决“在哪一层处理”打分解决“处理到什么程度”。我在实际系统里用的结构大致是三层第一层是确定性规则层处理那些没有任何争议的输入。格式不合法的直接拒命中黑名单的直接拒。这一层要快、要准、要不依赖外部服务它承担了绝大部分流量。第二层是信号层把各种“有点可疑但不确定”的特征转成信号交给打分。全同数字、顺序数字、号段未识别、短时间同 IP 高频、同设备多账号这些都是信号不是判决。第三层是决策层按累计分数决定动作放行、放行但加验证要求短信验证码、要求滑块、限流、人工审核、拒绝。分数阈值需要根据业务调整注册场景和下单场景的阈值一定不一样。4.2 信号怎么设计可解释比精确更重要信号设计有个反直觉的结论早期阶段可解释性比模型精度更重要。原因很实际出了问题要能说清楚“为什么拦了这个用户”否则客诉处理、规则调整都没法做。我一开始也试过直接上模型效果指标好看但每次误伤都解释不清楚最后退回规则打分反而更稳。按前面几节提到的特征一组可落地的信号长这样信号触发条件分值说明格式异常归一化后不满足严格规则直接拒绝确定性规则不进打分全同数字11 位全部相同40典型占位模式顺序数字连续递增或递减30常见于测试与伪造号段未识别前缀不在号段表25新号段会误伤需配合放行策略号段与归属地不一致声明地区与前缀不符15可能是填错也可能是伪造同 IP 短时多号1 小时内同 IP 关联号码超过阈值30阈值按业务基线定同设备多账号同设备指纹关联账号超阈值35设备指纹需做隐私合规评估号码近期变更频繁短周期内多次改绑20结合时间窗口计算分值不是拍脑袋而是按“这个信号单独出现时我有多大的把握认为它是异常的”来定。全同数字单独出现把握很高给高分号段未识别单独出现把握一般新号段会误伤给中低分。累计分数落在不同区间的处置动作用一张阈值表管理累计分值处置动作适用场景0 到 29放行默认路径30 到 59放行要求完成短信验证注册、登录60 到 89限流 要求二次验证下单、改绑、提现90 及以上人工审核或拒绝高风险操作这张表要按业务分别维护不要搞一张全局表。注册场景的用户体验权重高阈值可以放宽资金相关操作阈值必须收紧。同一套信号、不同的阈值表是这个结构最好用的地方。4.3 号段数据与名单数据怎么维护风控的效果一半靠规则一半靠数据。号段表和名单表是两套需要长期维护的数据资产维护方式直接决定策略能不能持续生效。号段表前面说过要点是版本化、可回滚、有更新记录。名单表要复杂一些至少分三类明确黑名单确认的异常来源直接拒、灰名单可疑加分或加验证、白名单确认可信跳过部分校验。三类名单都要有有效期永久黑名单在长期运行后一定会积累误伤加个到期时间到期自动复审能省掉大量历史包袱。名单的写入必须留痕谁加的、什么原因、关联的工单号、预计解除时间。没有留痕的名单半年后没人敢动最后变成一堆谁也不知道来历的规则。这块我的做法是强制填写原因字段不填不允许提交宁可多加一步操作。5. 实操落地一套可以直接抄的校验与风控组合5.1 校验函数的完整实现思路把前面几层拼起来一个完整的校验入口大致是这样组织的。注意顺序归一化 → 字符校验 → 结构校验 → 号段校验 → 输出结果与信号前四步任何一步失败都直接返回只有全部通过才进入信号计算。const SEGMENT_TABLE loadSegments(); // 版本化加载带缓存 function validateMobile(raw) { const normalized normalize(raw ?? ); // 字符层 if (!/^\d$/.test(normalized)) { return { ok: false, code: FORMAT, reason: non-digit }; } // 结构层 if (normalized.length ! 11) { return { ok: false, code: FORMAT, reason: length }; } // 号段层 const prefix normalized.slice(0, 3); const seg SEGMENT_TABLE.get(prefix); const signals []; if (!seg) signals.push({ key: unknown_segment, score: 25 }); if (/^(\d)\1{10}$/.test(normalized)) signals.push({ key: all_same, score: 40 }); if (isSequential(normalized)) signals.push({ key: sequential, score: 30 }); return { ok: true, normalized, segmentKnown: Boolean(seg), signals }; }这段代码有几个刻意的设计。格式失败返回ok:false号段未识别返回ok:true但带信号这是前面说的“格式层做确定性判断、概率性判断下移”的直接体现。信号以数组返回而不是直接给分是为了让决策层有调整空间不同业务可以给同一信号不同的权重系数。isSequential的实现要注意边界递增和递减都要判而且要允许整体位移比如 23456789012 这类跨位序列不能只判最简单的连续。同时要加一条这个函数只产信号不做拒绝避免误伤真实存在的规律号码。5.2 决策层的接入方式校验函数返回信号数组之后决策层做的事是加权求和 阈值判断 动作下发输入signals来自校验层、上下文IP、设备、时间、业务场景 步骤1按业务场景取权重系数累加得分 步骤2叠加外部信号同IP频次、同设备账号数这些需要异步查询用超时兜底 步骤3按场景阈值表映射动作 步骤4记录决策快照哪些信号、各自分值、最终动作、规则版本号 步骤5下发动作同时把决策快照写入日志步骤 4 是这套结构最容易被省掉、也最不该省掉的一步。决策快照的价值在事后客诉来了能查、规则调整前后能对比、误伤率上升能定位到具体信号。快照里必须带规则版本号否则改了规则之后历史数据全部失去解释力。步骤 2 的超时兜底也很关键。外部信号查询比如查同 IP 频次如果依赖远程服务必须有严格超时我一般设 50 到 100 毫秒超时就按“无该信号”处理并记录一次降级。宁可少一个信号不能让整个校验链路卡住。5.3 灰度上线与效果验证风控策略最忌讳一次全量上线。新规则上线前先跑影子模式规则照常计算但不影响实际动作只记录“如果不放行会拦掉多少、其中有多少是真实用户”。跑一到两周看误伤比例再决定是否开启拦截。影子模式期间要盯三个数拦截率会拦掉多少流量、误伤率抽样确认被拦的是不是正常用户、漏放率该拦没拦的比例通过事后异常反馈倒推。这三个数决定了阈值怎么调。我一般的经验是注册场景的拦截率控制在千分级误伤率控制在万分位超过就要重新审视信号权重。灰度放量的节奏按流量切分5%、20%、50%、100%每一档观察至少一天重点看客诉量和验证码下发量的变化。验证码下发量是个很好的先行指标它涨得太多说明策略把大量正常用户推到了验证环节。注意策略调整一定要留回滚开关并且回滚操作要能在分钟级完成。线上策略出问题时改参数比改代码快改开关比改参数快。6. 常见问题与排查速查表6.1 排查思路先定位层再定位规则碰到“异常号码进了系统”这类问题我的排查顺序是固定的先确认从哪条路径进来的再确认那一层为什么没拦住。路径通常有四种单条表单提交、批量导入、第三方接口推送、历史数据迁移。四种路径的校验实现往往是四份代码问题多半出在后三种。定位之后看层。如果连长度都不对说明字符或结构层被绕过了如果长度对但号段不对说明号段层缺失或号段表过期如果都过但行为异常说明信号和决策层没接上。按这个顺序查比漫无目的地读代码快得多。现象可能原因排查动作处理方式异常号码能注册接口未做严格校验检查接口入参校验链路复用统一校验器批量导入出现脏数据导入路径未复用校验查导入代码的校验调用强制复用 逐行结果新号段用户被拒号段表过期查号段表版本与更新时间更新表 未知前缀放行兜底正常用户被要求多次验证信号阈值过严看决策快照的信号分布调权重或阈值短信量突增频控缺失或维度单一查号码/IP/设备三维度频控补齐维度 统一文案客诉说“号码没错但被拦”归一化误伤或名单误伤查归一化结果与名单来源修归一化 名单加有效期改绑后账号异常历史脏值参与关联跑全量盘点打标隔离不参与关键流程策略调整后效果不明缺少规则版本与快照查日志结构补决策快照与版本号6.2 几个踩过的坑坑一把“未知号段”当异常直接拒绝。上线第二天就遇到一批新放号段的用户全部注册失败客诉集中爆发。改成“放行 打标 降信任分”之后同类问题再没出现过。教训是确定性规则只拦确定错误不确定的一律交给打分。坑二前后端规则各写一份慢慢漂移。前端改了长度上限后端没改导致前端放行的数据在后端被拒用户看到的是“提交成功但没反应”。后来改成配置驱动、前后端读同一份参数这类问题归零。规则参数化的收益在第一次改规则的时候就能体现出来。坑三频控只按号码被换号绕过。早期的频控只统计单个号码的发送次数攻击方每次换一个号频控形同虚设短信费用一天之内涨了好几倍。补齐 IP 和设备维度之后才压住。这件事让我形成一个习惯任何限流都要问一句“换个维度还能不能绕过”。坑四名单只加不减最后没人敢动。灰名单积累到几万条之后误伤开始零星出现但没人知道某条记录当初为什么加进去。后来强制要求填写原因和有效期到期自动复审名单才重新变得可用。数据治理的很多问题根子都在“没有留痕”。坑五把校验逻辑写在页面里接口裸奔。这个问题在早期项目里几乎必然出现一次。绕过成本极低发现时通常已经积累了脏数据。正确的心理预期是前端校验永远不会被执行接口校验永远会。6.3 一套可以直接用的自查清单上线前对着这张清单过一遍能挡掉大部分低级问题归一化逻辑是否只有一份是否覆盖全角、空白、零宽字符严格校验和宽松校验是否分成两个校验器语义是否清晰接口层是否独立执行了完整校验是否与前端读同一份规则参数批量导入、第三方推送、数据迁移三条路径是否复用同一校验器号段表是否有版本、有更新记录、有未知前缀兜底频控是否覆盖号码、IP、设备三个维度超限文案是否统一信号是否只产分不判决决策层是否有场景化阈值表决策日志是否包含信号明细、分值、动作、规则版本号名单是否有原因、有效期、复审机制策略是否有回滚开关回滚是否能在分钟级完成。7. 我在实际项目里的几点体会号码校验这件事看起来是正则表达式的问题做久了会发现它其实是分层思维的问题。哪一层做确定性判断、哪一层做概率判断、哪一层花钱、哪一层不能花钱把这条线划清楚绝大多数坑都能提前避开。反过来把所有判断塞进一个函数里短期写着快长期一定会在某个没想到的入口漏出去。另一个体会是关于“严”的。很多团队遇到异常数据的第一反应是把规则收紧长度卡死、号段卡死、名单卡死。收紧确实能挡住眼前的异常但每一次收紧都在积累误伤而误伤的代价往往比漏放更高——漏放是数据脏一点误伤是真实用户用不了产品。所以我的默认倾向是格式从严、存在性从宽、行为看信号让拦截发生在该发生的地方而不是最早能发生的地方。最后一个习惯分享给你每次调整校验或风控规则我都要求自己在日志里留一条“变更说明”写清楚改了什么、为什么改、预期影响哪些指标、怎么回滚。这条说明只有几十个字但在半年后回头看时它比任何文档都有用。规则是会生长的能读懂自己半年前为什么这么写比写出更复杂的规则更重要。
1. 一串“魔鬼数字”到底在测什么半夜手机响屏幕上是一串几乎不像是号码的数字十个 9 排成一排。第一反应往往是“谁在恶作剧”第二反应是“这号码能拨通吗”。我做号码相关的业务系统有些年头了每次碰到这类截图关注点从来不是“吓不吓人”而是它把三个平时藏在系统底层的问题一次性摆到了台面上手机号校验规则到底有多松、特殊数字序列为什么总能穿过校验、风控面对这种输入到底该拦还是该放。这串“魔鬼数字”本身不神秘。它既不是某个地区的真实号段也不是什么隐藏彩蛋本质就是一段符合长度、但不符合真实号段分配规则的字符串。问题在于很多系统在校验时只做了“长度对不对”“是不是全数字”这两件事于是一串 9 就能大摇大摆走完注册、登录、短信下发、订单创建的全流程。等业务方发现异常往往已经是脏数据堆积、短信通道被刷、用户被骚扰之后了。这篇内容适合三类人看。第一类是正在写注册登录、表单校验的前后端开发者你需要知道校验要分几层、每层拦什么第二类是做过或正在做风控策略的同学你会看到单点规则为什么不够、组合策略怎么设计第三类是对接短信通道、做号码清洗的数据同学你能拿到一套可以直接抄的判定思路和排查表。全文围绕手机号校验、魔鬼数字、风控策略三个关键词展开不聊玄学只聊能落地的规则、参数和踩过的坑。需要先说明一点下文涉及的所有号码、号段、案例均为示意性描述用于说明校验逻辑不指向任何真实用户或真实事件。真实系统的号段数据应当以通信管理部门的公开分配文件为准定期更新这一点后面会专门讲。2. 手机号校验的四层结构从“像不像”到“是不是”2.1 第一层字符层先把“长得不像”的挡在门外字符层校验是最便宜的一道闸成本几乎为零却能被大量系统漏掉。它的职责很单纯判断这串输入在字符构成上有没有资格被当作号码。具体要拦的东西包括空值、首尾空格、全角数字、夹杂字母、夹杂横杠括号、Unicode 里那些长得像数字的字符比如某些语系里的数字符号以及各种零宽字符。这里有个很容易被忽略的点全角数字和半角数字在肉眼上几乎一样但在字符串比较里是两个世界。用户在中文输入法状态下敲出的“”如果直接入库后续所有基于半角规则的判断全部失效。我见过一个表单前端用正则卡了半角用户复制粘贴全角进去之后前端没拦住因为某些输入法会做自动转换后端也没做归一化结果这条数据在报表里显示正常、在检索时永远查不到。处理思路是先归一化再校验顺序不能反// 归一化全角转半角、去除空白与不可见字符 function normalize(raw) { if (typeof raw ! string) return ; return raw .replace(/[\uFF10-\uFF19]/g, ch String.fromCharCode(ch.charCodeAt(0) - 0xFEE0)) .replace(/[\u200B-\u200D\uFEFF]/g, ) .replace(/[\s\-()]/g, ); }归一化之后再做字符白名单判断只允许纯数字长度单独交给下一层。这样做的好处是归一的逻辑只写一次入库、比对、展示全部复用同一份结果避免“前端一套、后端一套、导出又一套”的三套规则打架。注意归一化会改变用户原始输入如果业务上有“保留原始输入用于审计”的需求要同时存原始值和归一化值两个字段别只留一个。字符层还有一个细节空字符串和 null 要区分处理。空字符串通常意味着用户提交了表单但没填属于业务校验失败null 往往意味着调用方漏传参数属于接口契约问题。这两种情况返回给前端的错误码和文案应该不一样否则排查线上问题时根本分不清是用户的问题还是调用方的问题。2.2 第二层结构层长度与格式的硬约束结构层管的是“形状”。国内手机号是11 位纯数字这是硬约束不多不少。很多系统的校验写成length 10 length 13这种宽松区间本意是兼容各类号码座机、境外号结果把 10 个 9 这种输入放进了主流程这就是标题里那串数字能进来的直接原因之一。宽松区间本身不是错错在没有分场景。同一个表单里可能同时存在“手机号”和“联系电话”两种语义前者必须严格 11 位后者可能允许座机、允许分机号、允许境外格式。做法是把校验器拆成两个校验器适用字段规则失败处理strictMobile注册、登录、短信下发、实名归一化后严格 11 位纯数字且首两位命中当前号段直接拒绝提示格式错误looseContact联系地址、备注、客服工单允许数字、横杠、括号、加号长度 5 到 20放行但标记为“非标准号码”进入人工复核队列表格里最右列是这套设计的关键。宽松校验不等于不校验而是要有一个“降级处理”的去处。很多系统的问题就在这儿要么全严把座机用户挡在门外要么全松把脏数据放进来。分成两条通道之后严格通道保持高门槛宽松通道把风险外溢到后置环节风险就变得可控、可观测。还有一个常被忽视的结构约束号码里不能出现连续过长或过度规律的重复。这里要小心重复判断本身很容易误伤比如某些真实号段天然带有重复特征。所以这条规则不能放在“格式校验”里直接拒绝而应该作为风险信号交给风控层打分这是后面第 4 节要展开的内容。格式层只做确定性判断概率性判断一律下移这条分界线我建议你划清楚。2.3 第三层号段层判断“这个号码理论上存在吗”长度对了、全是数字还不代表这个号码真实存在。号段的分配是有规则的前几位决定了它属于哪家运营方、属于哪类业务。校验的第三层就是拿号码前缀去比对一个定期更新的号段表。层的关键在于数据要活。号段会新增、会调整靠硬编码在代码里的常量迟早过期。我建议的形态是号段表独立存储可以是配置表、也可以是缓存里的一个集合应用启动时加载表结构至少包含前缀、位数、运营方标识、启用状态、生效时间、失效时间每次校验走缓存缓存有版本号配置变更后按版本失效避免全量刷新时的抖动保留一条“未知前缀”的兜底路径不至于因为号段表漏了一个新前缀就把正常用户全拒了。兜底路径怎么写直接决定系统的健壮性。我的做法是未知前缀默认放行但打标记允许完成注册同时给这条记录加上“号段未识别”的内部标签并降低该账号的初始信任分。这样既不误伤新号段的真实用户又给后续风控留了抓手。反过来“未知前缀直接拒绝”看起来很严实际上每逢号段更新就会引发一批客诉得不偿失。提示号段表一定要有更新机制和更新记录。出了问题第一件事是查“号段表最后一次更新是什么时候、谁改的、改了什么”没有这条记录排查会非常痛苦。2.4 第四层存在性校验成本最高必须最后做前三层都是本地判断第四层要花钱短信验证码、语音回拨、运营商三要素核验都是按次计费的。所以这一层的定位是最终确认绝对不能放在表单输入的实时校验里。这层最容易出的事故是顺序颠倒。我见过一个注册流程用户敲完第 11 位数字前端立刻调接口查号段、调接口发短信用户还在改最后一位短信已经发了三条。正确的做法是把发短信绑定在明确动作上点击“获取验证码”并且加上前端冷却和后端频控双保险前端冷却同页面同号码 60 秒内不可再次触发仅体验层可绕过 后端频控按号码 1 次/分钟、5 次/小时、10 次/天按来源IP 20 次/小时按设备指纹 10 次/小时 超限处理返回统一提示不区分是哪个维度命中避免被用来探测规则频控维度这里多说一句。只按号码限流是不够的攻击方换号就行只按 IP 限流也不够IP 池的成本很低。号码 IP 设备指纹三者的组合才是相对稳的结构任何一个维度超限都拦但对外返回的文案必须统一否则等于把规则白送出去。3. “魔鬼数字”为什么总能穿过校验五类典型漏洞3.1 漏洞一正则写宽了宽松成了默认值最常见的写法是^\d{6,15}$这类区间正则。作者的本意是“兼容各种号码”实际效果是任何 6 到 15 位的数字串都能过。10 个 9 正好 10 位稳稳落在区间里。这类正则的危险性在于它看起来很专业code review 时容易被放过。我的判断标准很简单凡是面向单一业务语义的字段注册手机号正则必须是精确的只有面向“备注、描述、补充联系方式”的开放字段才允许区间。同一个校验函数如果被两个语义不同的字段共用那就是隐患的源头。改法不是把正则收紧就完事而是拆函数。上面 2.2 里的 strictMobile 和 looseContact 就是这个思路。拆分之后严格通道的正则可以写成更精确的形式并且叠加号段判断10 个 9 在号段层就会被拦掉。3.2 漏洞二只做前端校验接口裸奔前端校验的定位是提升体验不是安全边界。绕过它只需要打开调试工具或者直接构造请求成本极低。我做过统计一个上线一段时间的产品如果只在表单上做校验接口层的异常号码占比通常在千分之几到百分之几之间具体取决于产品有没有被盯上。正确做法是同一份规则前后端各实现一次以后端为准。前端那份负责即时反馈后端那份负责最终裁决。为了避免两边规则漂移我的经验是把规则参数化长度、允许字符集、号段表版本全部放在配置里前后端读同一份配置前端在构建时注入后端运行时加载。规则要改就改配置不改代码漂移的概率会小很多。注意前端不要泄露过细的失败原因。“号码不存在”和“号码格式错误”这类细分提示在校验阶段应该合并成统一文案细分原因只写日志。原因很简单细分提示等于给探测者提供了一台免费的规则查询机。3.3 漏洞三批量导入接口漏掉了同一套校验这是我在实际系统里见过最多的一类问题。单个新增走的是严格校验批量导入走的是另一条代码路径而那条路径往往只做了“非空判断”。10 条也好10 万条也好全部原样入库。批量导入必须复用同一套校验器这一点没有讨论空间。工程上的做法是把校验抽成独立模块单条新增和批量导入都调它不允许任何一条路径自己写判断。批量场景还要额外加两条逐行返回结果成功多少、失败多少、失败行的行号和原因全部落库便于业务方修正后重传设置单次导入上限和总量阈值比如单次不超过 5 万行超过走异步任务异常率超过某个比例例如 30%时中止整批避免把一批脏数据一次性灌进去。3.4 漏洞四历史数据里的脏值影响了新逻辑老系统留下的数据往往带着历史宽松规则的痕迹。这些数据平时不显眼一旦做号码相关的功能迭代就会冒出来号码补全、号码去重、按号码关联账号全都会踩。处理历史脏数据要有节奏。第一步是盘点按规则跑一遍全量统计各类异常的数量和分布先做到心里有数第二步是隔离把异常记录打标不参与依赖号码的关键流程比如不用于账号合并、不用于营销触达第三步才是清洗能补全的补全补不了的保持标记状态别强行改。强行把 10 个 9 改成某个真实号码是最糟糕的处理方式。表格形式的盘点结果是我每次做这类治理时必交的东西异常类型判定规则预估占比处置动作长度异常归一化后位数不等于目标位数待统计打标不参与关键流程全同数字所有字符相同待统计打标进入人工复核顺序列连续递增或递减如 12345678待统计打标进入人工复核号段未识别前缀不在当前号段表待统计打标降低初始信任分明显伪造常见占位模式全 0、全 9 等待统计打标禁止用于触达3.5 漏洞五异常输入直接进了下游放大成事故这一条是前面几条的后果但值得单独拎出来说。一个异常号码本身不可怕可怕的是它进了短信通道、进了营销名单、进了外呼任务。短信通道被刷是直接的钱营销触达异常号码可能引发投诉外呼任务里的假号码会白白消耗坐席时间。防的手段是在下游入口加一道号码质量闸。任何批量触达任务在创建时先按上面的判定规则过滤一遍把异常号码剔出来单独处理不混在正常任务里执行。这道闸的成本很低收益是把事故挡在花钱之前。4. 风控策略怎么搭从单点规则到分层打分4.1 为什么单点规则一定会失效单点规则的特点是“一刀切”命中就拦不命中就放。它的问题不在于不严而在于无法表达程度。10 个 9 明显异常一个正常的 11 位号码也可能因为用户手滑少敲一位两者在单点规则下要么都被拦、要么都被放没有中间态。风控要解决的是这个“中间态”所以结构上必须是分层 打分。分层解决“在哪一层处理”打分解决“处理到什么程度”。我在实际系统里用的结构大致是三层第一层是确定性规则层处理那些没有任何争议的输入。格式不合法的直接拒命中黑名单的直接拒。这一层要快、要准、要不依赖外部服务它承担了绝大部分流量。第二层是信号层把各种“有点可疑但不确定”的特征转成信号交给打分。全同数字、顺序数字、号段未识别、短时间同 IP 高频、同设备多账号这些都是信号不是判决。第三层是决策层按累计分数决定动作放行、放行但加验证要求短信验证码、要求滑块、限流、人工审核、拒绝。分数阈值需要根据业务调整注册场景和下单场景的阈值一定不一样。4.2 信号怎么设计可解释比精确更重要信号设计有个反直觉的结论早期阶段可解释性比模型精度更重要。原因很实际出了问题要能说清楚“为什么拦了这个用户”否则客诉处理、规则调整都没法做。我一开始也试过直接上模型效果指标好看但每次误伤都解释不清楚最后退回规则打分反而更稳。按前面几节提到的特征一组可落地的信号长这样信号触发条件分值说明格式异常归一化后不满足严格规则直接拒绝确定性规则不进打分全同数字11 位全部相同40典型占位模式顺序数字连续递增或递减30常见于测试与伪造号段未识别前缀不在号段表25新号段会误伤需配合放行策略号段与归属地不一致声明地区与前缀不符15可能是填错也可能是伪造同 IP 短时多号1 小时内同 IP 关联号码超过阈值30阈值按业务基线定同设备多账号同设备指纹关联账号超阈值35设备指纹需做隐私合规评估号码近期变更频繁短周期内多次改绑20结合时间窗口计算分值不是拍脑袋而是按“这个信号单独出现时我有多大的把握认为它是异常的”来定。全同数字单独出现把握很高给高分号段未识别单独出现把握一般新号段会误伤给中低分。累计分数落在不同区间的处置动作用一张阈值表管理累计分值处置动作适用场景0 到 29放行默认路径30 到 59放行要求完成短信验证注册、登录60 到 89限流 要求二次验证下单、改绑、提现90 及以上人工审核或拒绝高风险操作这张表要按业务分别维护不要搞一张全局表。注册场景的用户体验权重高阈值可以放宽资金相关操作阈值必须收紧。同一套信号、不同的阈值表是这个结构最好用的地方。4.3 号段数据与名单数据怎么维护风控的效果一半靠规则一半靠数据。号段表和名单表是两套需要长期维护的数据资产维护方式直接决定策略能不能持续生效。号段表前面说过要点是版本化、可回滚、有更新记录。名单表要复杂一些至少分三类明确黑名单确认的异常来源直接拒、灰名单可疑加分或加验证、白名单确认可信跳过部分校验。三类名单都要有有效期永久黑名单在长期运行后一定会积累误伤加个到期时间到期自动复审能省掉大量历史包袱。名单的写入必须留痕谁加的、什么原因、关联的工单号、预计解除时间。没有留痕的名单半年后没人敢动最后变成一堆谁也不知道来历的规则。这块我的做法是强制填写原因字段不填不允许提交宁可多加一步操作。5. 实操落地一套可以直接抄的校验与风控组合5.1 校验函数的完整实现思路把前面几层拼起来一个完整的校验入口大致是这样组织的。注意顺序归一化 → 字符校验 → 结构校验 → 号段校验 → 输出结果与信号前四步任何一步失败都直接返回只有全部通过才进入信号计算。const SEGMENT_TABLE loadSegments(); // 版本化加载带缓存 function validateMobile(raw) { const normalized normalize(raw ?? ); // 字符层 if (!/^\d$/.test(normalized)) { return { ok: false, code: FORMAT, reason: non-digit }; } // 结构层 if (normalized.length ! 11) { return { ok: false, code: FORMAT, reason: length }; } // 号段层 const prefix normalized.slice(0, 3); const seg SEGMENT_TABLE.get(prefix); const signals []; if (!seg) signals.push({ key: unknown_segment, score: 25 }); if (/^(\d)\1{10}$/.test(normalized)) signals.push({ key: all_same, score: 40 }); if (isSequential(normalized)) signals.push({ key: sequential, score: 30 }); return { ok: true, normalized, segmentKnown: Boolean(seg), signals }; }这段代码有几个刻意的设计。格式失败返回ok:false号段未识别返回ok:true但带信号这是前面说的“格式层做确定性判断、概率性判断下移”的直接体现。信号以数组返回而不是直接给分是为了让决策层有调整空间不同业务可以给同一信号不同的权重系数。isSequential的实现要注意边界递增和递减都要判而且要允许整体位移比如 23456789012 这类跨位序列不能只判最简单的连续。同时要加一条这个函数只产信号不做拒绝避免误伤真实存在的规律号码。5.2 决策层的接入方式校验函数返回信号数组之后决策层做的事是加权求和 阈值判断 动作下发输入signals来自校验层、上下文IP、设备、时间、业务场景 步骤1按业务场景取权重系数累加得分 步骤2叠加外部信号同IP频次、同设备账号数这些需要异步查询用超时兜底 步骤3按场景阈值表映射动作 步骤4记录决策快照哪些信号、各自分值、最终动作、规则版本号 步骤5下发动作同时把决策快照写入日志步骤 4 是这套结构最容易被省掉、也最不该省掉的一步。决策快照的价值在事后客诉来了能查、规则调整前后能对比、误伤率上升能定位到具体信号。快照里必须带规则版本号否则改了规则之后历史数据全部失去解释力。步骤 2 的超时兜底也很关键。外部信号查询比如查同 IP 频次如果依赖远程服务必须有严格超时我一般设 50 到 100 毫秒超时就按“无该信号”处理并记录一次降级。宁可少一个信号不能让整个校验链路卡住。5.3 灰度上线与效果验证风控策略最忌讳一次全量上线。新规则上线前先跑影子模式规则照常计算但不影响实际动作只记录“如果不放行会拦掉多少、其中有多少是真实用户”。跑一到两周看误伤比例再决定是否开启拦截。影子模式期间要盯三个数拦截率会拦掉多少流量、误伤率抽样确认被拦的是不是正常用户、漏放率该拦没拦的比例通过事后异常反馈倒推。这三个数决定了阈值怎么调。我一般的经验是注册场景的拦截率控制在千分级误伤率控制在万分位超过就要重新审视信号权重。灰度放量的节奏按流量切分5%、20%、50%、100%每一档观察至少一天重点看客诉量和验证码下发量的变化。验证码下发量是个很好的先行指标它涨得太多说明策略把大量正常用户推到了验证环节。注意策略调整一定要留回滚开关并且回滚操作要能在分钟级完成。线上策略出问题时改参数比改代码快改开关比改参数快。6. 常见问题与排查速查表6.1 排查思路先定位层再定位规则碰到“异常号码进了系统”这类问题我的排查顺序是固定的先确认从哪条路径进来的再确认那一层为什么没拦住。路径通常有四种单条表单提交、批量导入、第三方接口推送、历史数据迁移。四种路径的校验实现往往是四份代码问题多半出在后三种。定位之后看层。如果连长度都不对说明字符或结构层被绕过了如果长度对但号段不对说明号段层缺失或号段表过期如果都过但行为异常说明信号和决策层没接上。按这个顺序查比漫无目的地读代码快得多。现象可能原因排查动作处理方式异常号码能注册接口未做严格校验检查接口入参校验链路复用统一校验器批量导入出现脏数据导入路径未复用校验查导入代码的校验调用强制复用 逐行结果新号段用户被拒号段表过期查号段表版本与更新时间更新表 未知前缀放行兜底正常用户被要求多次验证信号阈值过严看决策快照的信号分布调权重或阈值短信量突增频控缺失或维度单一查号码/IP/设备三维度频控补齐维度 统一文案客诉说“号码没错但被拦”归一化误伤或名单误伤查归一化结果与名单来源修归一化 名单加有效期改绑后账号异常历史脏值参与关联跑全量盘点打标隔离不参与关键流程策略调整后效果不明缺少规则版本与快照查日志结构补决策快照与版本号6.2 几个踩过的坑坑一把“未知号段”当异常直接拒绝。上线第二天就遇到一批新放号段的用户全部注册失败客诉集中爆发。改成“放行 打标 降信任分”之后同类问题再没出现过。教训是确定性规则只拦确定错误不确定的一律交给打分。坑二前后端规则各写一份慢慢漂移。前端改了长度上限后端没改导致前端放行的数据在后端被拒用户看到的是“提交成功但没反应”。后来改成配置驱动、前后端读同一份参数这类问题归零。规则参数化的收益在第一次改规则的时候就能体现出来。坑三频控只按号码被换号绕过。早期的频控只统计单个号码的发送次数攻击方每次换一个号频控形同虚设短信费用一天之内涨了好几倍。补齐 IP 和设备维度之后才压住。这件事让我形成一个习惯任何限流都要问一句“换个维度还能不能绕过”。坑四名单只加不减最后没人敢动。灰名单积累到几万条之后误伤开始零星出现但没人知道某条记录当初为什么加进去。后来强制要求填写原因和有效期到期自动复审名单才重新变得可用。数据治理的很多问题根子都在“没有留痕”。坑五把校验逻辑写在页面里接口裸奔。这个问题在早期项目里几乎必然出现一次。绕过成本极低发现时通常已经积累了脏数据。正确的心理预期是前端校验永远不会被执行接口校验永远会。6.3 一套可以直接用的自查清单上线前对着这张清单过一遍能挡掉大部分低级问题归一化逻辑是否只有一份是否覆盖全角、空白、零宽字符严格校验和宽松校验是否分成两个校验器语义是否清晰接口层是否独立执行了完整校验是否与前端读同一份规则参数批量导入、第三方推送、数据迁移三条路径是否复用同一校验器号段表是否有版本、有更新记录、有未知前缀兜底频控是否覆盖号码、IP、设备三个维度超限文案是否统一信号是否只产分不判决决策层是否有场景化阈值表决策日志是否包含信号明细、分值、动作、规则版本号名单是否有原因、有效期、复审机制策略是否有回滚开关回滚是否能在分钟级完成。7. 我在实际项目里的几点体会号码校验这件事看起来是正则表达式的问题做久了会发现它其实是分层思维的问题。哪一层做确定性判断、哪一层做概率判断、哪一层花钱、哪一层不能花钱把这条线划清楚绝大多数坑都能提前避开。反过来把所有判断塞进一个函数里短期写着快长期一定会在某个没想到的入口漏出去。另一个体会是关于“严”的。很多团队遇到异常数据的第一反应是把规则收紧长度卡死、号段卡死、名单卡死。收紧确实能挡住眼前的异常但每一次收紧都在积累误伤而误伤的代价往往比漏放更高——漏放是数据脏一点误伤是真实用户用不了产品。所以我的默认倾向是格式从严、存在性从宽、行为看信号让拦截发生在该发生的地方而不是最早能发生的地方。最后一个习惯分享给你每次调整校验或风控规则我都要求自己在日志里留一条“变更说明”写清楚改了什么、为什么改、预期影响哪些指标、怎么回滚。这条说明只有几十个字但在半年后回头看时它比任何文档都有用。规则是会生长的能读懂自己半年前为什么这么写比写出更复杂的规则更重要。
