事情本身不复杂，线索都在日志里。脱敏把手机号处理成保留前三位和后四位的形式，看着没问题，但分析库里有十几万条记录，把掩码位置和号段结合后仍能缩小到几十个候选，风控同事据此还原出了一批真实号码。
第一反应是「只替换中间几位，长度和分段结构完全没有变」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。保留位数太多，号段加后四位已经接近唯一。还有一种是同一用户在各表掩码规则一致，可以互相关联。
少数情况下是脱敏后的字段还参与精确匹配查询。
估算当前掩码规则的候选空间
python -c "print(10**4*3)"随后改成只保留后两位且不保留号段
python -c "p='13800001111';print('*'*(len(p)-2)+p[-2:])"然后按场景分级：分析全掩码，客服保留后四位
python mask.py --field phone --policy analytics=full,service=tail4剩下的就是抽样评估还原难度与业务可用性
python eval_mask.py --sample 1000 --check uniqueness恢复的判定其实很直接。分析库里同一掩码值对应上万条真实号码，客服场景仍能看到后四位，风控无法再从小样本反推出个体。
这里还有个坑。掩码要按使用场景分级，保留位数越多越好看也越接近可还原，长度和号段本身就是线索。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。