必须脱敏密码、身份证号、手机号、银行卡号、邮箱地址、jwt token 等强敏感字段；应优先在结构化日志中对明确字段精准脱敏，避免全文正则扫描，推荐使用预编译正则与 logging.filter 实现高效、可控的字段级脱敏。
日志中哪些字段必须脱敏
密码、身份证号、手机号、银行卡号、邮箱地址、JWT token 这几类是强敏感字段，不脱敏就上生产等于裸奔。但别一上来就写个巨长正则匹配所有——比如用 .*?(\d{17}[\dXx]|\d{11}|[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}).* 这种“万能”模式，它会吃掉大量 CPU，尤其在高并发日志写入时，logging 线程可能被卡住。
实际做法是：只对明确知道会含敏感信息的字段做精准匹配。比如你记录的是 user_info 字典，那就只对 user_info['id_card']、user_info['phone'] 这些键值脱敏，而不是对整条日志文本扫一遍。
- 优先在结构化日志（如 JSON 格式）中做字段级脱敏，而非对
%(message)s做全文正则 - 避免在
Formatter.format()里调用re.sub()处理整条日志字符串 - 如果必须全文扫描，用预编译的
re.compile()对象，且正则尽量窄（比如手机号限定为r'1[3-9]\d{9}'，而非r'\d{11}'）
用 Filter 还是 Processor 脱敏更稳
Python 的 logging.Filter 是最轻量、最可控的方式；而像 structlog 的 processor 或 loguru 的 patch() 属于更高层封装，容易掩盖脱敏时机问题。
Filter 在日志 record 创建后、格式化前介入，能直接修改 record.__dict__，不影响性能，也绕过字符串拼接阶段。但注意：它不能改 record.msg 里的占位符参数（比如 logger.info("user=%s", user_dict) 中的 user_dict），只能处理已展开的 record.message 或你手动塞进 record 的自定义字段。
立即学习“Python免费学习笔记（深入）”；
- 适合场景：结构化字段已存在
record.extra或你通过LoggerAdapter注入的字段 - 不适用场景：想动态脱敏
logger.info("token: %s", raw_token)中的raw_token——这时得提前处理变量，或换用loguru的patch()拦截 - 别在
filter()里做耗时操作（如查数据库、调 API），它运行在日志主线程里
正则写太宽会拖慢整个 logging 流程
一个典型错误是写 re.sub(r'.*password\s*[:=]\s*(\S+)', r'password=***', msg) ——这会导致回溯爆炸，尤其当 msg 含大量空格或特殊符号时，PCRE 引擎可能卡住几十毫秒。实测在 QPS 500+ 的服务里，这种正则会让日志延迟从 0.2ms 涨到 15ms+。
真正高效的写法是：锚定边界 + 限定长度 + 禁用贪婪。比如脱敏 JSON 日志中的 password 字段，用 r'"password"\s*:\s*"[^"]{8,64}"'，配合 re.IGNORECASE 和预编译。
- 永远用
re.compile(..., re.DOTALL | re.IGNORECASE)预编译，不要每次 format 都re.sub() - 避免
.*开头，改用[^"]*或\w+等有界表达式 - 对超长字段（如 base64 token）加长度限制，比如
r'[A-Za-z0-9+/]{20,500}={0,2}'，防止误匹配整个 HTML 响应体
JSON 日志里嵌套字段怎么安全脱敏
结构化日志里常见 {"user": {"profile": {"phone": "138****1234"}}} 这种嵌套，用正则硬扫 JSON 字符串风险极高——一旦 JSON 格式稍有变动（比如 key 加了空格、value 是 null），正则就失效或错脱敏。正确方式是解析后遍历字段。
但别真在每条日志里 json.loads() ——那比正则还慢。折中方案：只对已知路径做浅层提取。比如用 record.json_data.get('user', {}).get('profile', {}).get('phone')，再替换。前提是你的日志框架支持把结构体存进 record 属性（loguru 和 structlog 原生支持，原生 logging 需要自定义 LoggerAdapter）。
- 如果必须用原生
logging，建议在业务代码里提前脱敏字段，再传给 logger，而不是指望日志层兜底 - 别对整个 JSON 字符串做
re.sub()，哪怕用了re.escape()包裹 key 名，JSON 的转义和嵌套仍会导致漏匹配 - 注意
None、int、bool类型字段不会被字符串正则捕获，脱敏逻辑要单独判空或类型
脱敏不是加一层正则就完事，关键是控制作用域——越早、越窄、越结构化，越不容易翻车。线上日志管道里混着调试信息、用户输入、第三方响应，一个没压住的 re.sub() 就能让吞吐掉一半。
