事情本身不复杂，线索都在日志里。合规扫描报告指出日志里有 3800 条 11 位手机号明文，采集用的是 filebeat，应用层只对正常日志做了脱敏，异常堆栈里打印的请求参数全都原样落盘。
第一反应是「第三方库的日志没有接入脱敏」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。只对成功路径脱敏，异常分支没走同一套规则。少数情况下是堆栈里直接打印了原始请求对象。
另外，历史日志没有回溯清理。
定位明文集中在哪些字段
python scan_pii.py --dir /var/log/app --pattern '1[3-9]\\d{9}' --group field然后把脱敏放到序列化层统一处理
logger.info('req=%s', mask_pii(json.dumps(payload, ensure_ascii=False)))随后清理历史日志并重建索引
python purge_logs.py --from 2024-07-01 --mask phone --dry-run复扫确认条数归零
python scan_pii.py --dir /var/log/app --pattern '1[3-9]\\d{9}'改完先别撤，确认这几项。复扫结果为零，异常堆栈里的手机号显示为 138****0000，历史日志清理后磁盘占用也降了。
补一句。脱敏要放在统一出口而不是各个分支，异常路径才是最容易漏的地方，也是最容易被扫出来的。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。