问题出现得很突然，日志倒是留得挺全。脱敏正则写的是十七位数字加一位数字或大写 X，实际数据里末位有小写 x 和全角Ｘ，扫描发现 240 条没被替换，直接进了数据仓库。
刚开始盯着「正则没加边界，长数字串被整体跳过」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。正则没有覆盖小写与全角字符。还有一种是全角字符没有先做 NFKC 归一。
还有一种情况，脱敏只在一个服务里做，其他入口没接。
上来先用样本验证正则覆盖范围
python -c "import re;p=r'(?<!\\d)\\d{17}[\\dXx]';print([bool(re.search(p,s)) for s in ['11010119900101123X','11010119900101123x','１１０１０１１９９００１０１１２３Ｘ']])"随后统一先做 NFKC 归一化
s = unicodedata.normalize('NFKC', s)接着把脱敏收敛到一个公共函数
python mask_id.py --text sample.txt --keep 6,4 --check全量复扫并抽查抽样记录
python scan_pii.py --dir /data/warehouse --pattern '\\d{17}[\\dXx]' --limit 50怎么算真的好了，看的是同一批现象。三类写法都能被识别并替换成前六后四，复扫条数为零，抽样记录里没有残留。
补一句。脱敏正则最怕字符集不全，先归一化再匹配，大小写和全角各漏一次就是几百条。报错文案容易误导，真正的原因往往在相邻那一层的日志里。