java日志敏感信息脱敏应在落盘前识别替换，首选logback自定义converter，在%msg渲染阶段统一处理；需推动结构化日志、覆盖请求头与异常堆栈，并按字段类型实施差异化脱敏策略。
Java 中日志敏感信息脱敏，核心是“在日志落盘前识别并替换”，而不是事后清洗。关键不在于能不能做，而在于是否稳定、可维护、不影响排查效率。Logback 作为 Spring Boot 默认日志框架，提供了天然、低侵入的切入点。
优先用 Logback 自定义转换器（Converter）
这是最推荐的方式：在 %msg 渲染阶段对日志消息内容做统一处理，无需修改业务代码，也不依赖 AOP 或拦截器。你只需继承 ClassicConverter，重写 convert() 方法，在其中调用脱敏工具类即可。
- 支持正则匹配手机号、身份证、银行卡号、邮箱等常见模式，例如：
1[3-9]\d{9}、\d{17}[0-9Xx] - 保留原始格式结构，只替换敏感段，比如
"用户138****1234下单失败"而不是整条日志变"***" - 可配置开关（如
log.sensitive.mask.enabled=true），方便测试环境关闭、生产环境强制开启
结构化日志是脱敏落地的前提
如果日志还是 logger.info("订单 {} 用户 {} 金额 {}", orderId, phone, amount) 这种拼接字符串方式，脱敏只能靠正则模糊匹配，容易漏或误伤。应推动使用结构化日志（如 logger.info("order processed", kv("orderId", orderId), kv("phone", phone), kv("amount", amount))）。
- Logback 支持
StructuredArgument（需引入logback-classic1.4+），字段级可控，脱敏可精准到phone字段，不碰orderId - 配合 ELK 或 Loki，结构化字段还能用于权限隔离——比如限制普通运维人员无法查看
phone字段的原始值
别只盯业务参数，忽略请求头和异常堆栈
很多泄露事故来自被忽视的角落：HTTP Header 中的 Authorization、Cookie、X-Forwarded-For；或者 logger.error("调用失败", e) 打出的完整异常对象里嵌套了用户 Token 或明文密码。
- 自定义
Layout或Appender时，要同时处理ILoggingEvent.getFormattedMessage()和ILoggingEvent.getThrowableProxy() - 对 Header 脱敏建议白名单制：只允许记录
User-Agent、Content-Type等安全字段，其余一律过滤或掩码
脱敏策略按字段类型区分
不是所有敏感数据都适合“***”替换。不同场景需要不同算法：
- 手机号、身份证号：掩码（如 138****1234、110101****002X），保留校验位和地域特征，便于关联排查
-
银行卡号（PAN）：严格按 PCI DSS 标准，保留前6位（BIN）和后4位，中间全部掩码，例如
622848******1234 -
Token、密钥、密码：直接删除或固定替换为
[REDACTED]，不保留任何可推测信息 - 地址、姓名、订单备注：可考虑哈希（加盐）后记录，既保留唯一性用于链路追踪，又不可逆还原
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
