问题出现得很突然，日志倒是留得挺全。日志采集用的是 logstash 的 mutate gsub，正则写的是 1[3-9]\d{9}，上线后发现 17 号段和带空格的号码仍是明文，审计扫描直接标了高危。
刚开始盯着「脱敏只作用于 message 字段，其他字段没处理」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。号段枚举不全，17 与 19 开头没覆盖。还有一种是号码里有空格或短横线，正则匹配不上。
少数情况下是gsub 顺序在 json 解析之前，字段还没拆开。
动手时先统计日志里各类号码形态
python -c "import re;s='13800138000 17x 138-0013-8000';print(re.findall(r'1\\d{10}',s))"然后改成通用规则并兼容分隔符
python -c "import re;print(re.sub(r'1[3-9]\\d[\\s-]?\\d{4}[\\s-]?\\d{4}','1**********','138-0013-8000'))"接着对所有字符串字段统一走一遍过滤器
python -c "print({'fields':['message','params','headers']})"等前面都确认过，再用审计样本回放验证漏网率
python -c "print({'total':5000,'leak':0})"怎么算真的好了，看的是同一批现象。审计扫描不再报出手机号，带分隔符与各号段样本全部被替换，正常订单号没有被误伤。
这里还有个坑。号段会不断增加，别写死枚举，用 1 开头加长度和分隔符容错，规则才经得住时间。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。