这个坑值得记一笔。日志里把手机号替换成 PHONE_1、PHONE_2 这类占位符，同一份日志内还能通过出现顺序把人和订单对上，安全评审认为仍属于可识别信息。
刚开始盯着「脱敏只覆盖日志，链路追踪的 tag 仍是原文」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。占位符按出现顺序编号，天然保留了关联关系；同一请求的多条日志共用一套编号；导出给分析的宽表没有再做一次泛化。
第一件事是检查占位符是否可逆推
python -c "import re;s=open('app.log',encoding='utf-8').read();print(re.findall(r'PHONE_\d+',s)[:10])"接着改成按请求内哈希生成不可逆标识
python -c "import hashlib;print('PHONE_'+hashlib.sha256(b'13800001111').hexdigest()[:8])"再往下把 trace 的 tag 一并纳入脱敏规则
python -c "print('scrub tags: user.phone, user.id_card, http.header.authorization')"等前面都确认过，再对导出宽表做泛化并抽样复核
python generalize.py --in export.csv --cols phone,id_card --out export_g.csv别只看报错消失，验证要多做一步。同一手机号在不同日志里得到稳定但不可逆的标识，跨日志关联只剩同一请求内可见，安全评审复核通过。
补一句。脱敏的目标是不可区分而不是不可读，顺序编号这种写法看着安全，实际把关联关系完整保留了下来。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。