脱敏规则必须在日志解析前定义清楚，需按日志类型（如json、nginx）预设字段路径，结合jsonpath定位与预编译正则处理，启用开关控制，兼顾准确性、性能及可观察性。
脱敏规则必须在日志解析前定义清楚
生产日志格式五花八门，json、plain text、nginx access log、django request log 都可能混在一起。如果等解析完再判断字段是否要脱敏，容易漏掉嵌套结构里的敏感项（比如 user_data 里嵌了 id_card），也容易因正则误匹配导致日志损坏。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用字典结构预定义每种日志类型的脱敏路径，例如：
{"json": ["user.phone", "data.id_card"], "nginx": ["$remote_addr"]} - 对
json日志用jsonpath（如jsonpath-ng库）定位字段，别用.get()逐层取——嵌套缺失时会静默失败 - 对非结构化日志（如
nginx或django的%(message)s），先用re.compile预编译脱敏正则，避免每次re.sub重复编译 - 所有规则必须带启用开关（如
ENABLE_PII_MASKING = True），上线前默认关闭，灰度验证后再开
手机号、身份证号等正则脱敏要兼顾准确性和性能
用 re.sub(r'\d{11}', '***', log_line) 这类宽泛正则会把订单号、时间戳甚至 IP 地址都干掉；但写太细（比如严格校验身份证末位校验码）又拖慢处理速度，尤其单条日志超 10MB 时明显卡顿。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 手机号优先用：
r'1[3-9]\d{9}(?!\d)'—— 后置否定断言防止匹配到更长数字串 - 身份证号用两阶段：先粗筛
r'\d{17}[\dXx]'，再对匹配结果用re.fullmatch校验末位（仅对疑似项校验，不全量跑） - 所有正则加
re.IGNORECASE和re.UNICODE，避免中文括号或大小写X漏脱 - 脱敏后保留原始长度（如
'138****1234'），方便下游系统仍能按位置做字段切分
日志文件流式处理不能依赖 readlines()
生产日志动辄 GB 级，用 file.readlines() 一次性加载会 OOM；而 for line in file 虽然内存友好，但遇到超长行（比如堆栈 trace）或未换行结尾的尾部数据时，容易截断或丢数据。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
io.BufferedReader+readline()手动控制缓冲区大小（如buffer_size=8192），比默认值更稳 - 对可能含多行结构的日志（如
traceback），先按空行或时间戳正则分块，再对每块脱敏，而不是逐行硬切 - 写入脱敏后日志时，务必用
open(..., encoding='utf-8', errors='ignore')，避免UnicodeDecodeError导致整个管道中断 - 记录每批次处理的
offset和行号，失败时能从断点续跑，别靠重跑全量
脱敏脚本必须和日志采集链路解耦
直接改 rsyslog 或 filebeat 配置加过滤逻辑，看似省事，但一旦脱敏规则变更就得重启采集进程，影响日志实时性；更麻烦的是，不同环境（dev/staging/prod）的脱敏强度要求不同，硬编码进采集端会导致配置爆炸。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 脱敏作为独立服务运行，监听采集端输出的临时目录（如
/var/log/raw/），处理完移入/var/log/sanitized/—— 目录名本身就是环境标识 - 用
inotifywait或watchdog库监听新文件，避免轮询浪费 CPU - 每个脱敏任务生成
.meta.json文件，记录原始文件名、处理时间、脱敏字段列表、命中次数，供审计回溯 - 禁止在脱敏脚本里调用外部命令（如
subprocess.run(['sed', ...])），进程 fork 开销大且难以统一管控错误
真正难的不是写几个正则，而是让脱敏行为可观察、可回滚、不拖慢链路——尤其当某天 DBA 突然说“用户邮箱也要脱敏”，你得在不影响线上日志投递的前提下，十分钟内完成规则更新和验证。
