Java日志异常脱敏简化旨在防敏感信息泄露、提升可读性与可维护性，核心是不破坏堆栈完整性但过滤敏感字段、不删减调用链但压缩冗余帧；需递归脱敏异常链及MDC、精准简化堆栈帧、结构化输出并完整处理suppressed异常与嵌套cause。
Java 日志中记录异常堆栈时，脱敏与简化不是为了“隐藏错误”，而是防止敏感信息泄露、提升日志可读性与可维护性。核心在于：**不破坏堆栈完整性，但过滤掉不该出现的字段；不删减调用链，但压缩冗余路径和无意义帧**。
脱敏：拦截敏感字段，而非屏蔽整个堆栈
异常堆栈本身（printStackTrace() 或 logger.error("msg", e) 输出）会递归打印异常对象及其 cause、suppressed 异常，还可能触发 toString() 或 JSON 序列化——这时若对象含密码、身份证、token 等字段，就会原样暴露。
- 不要在实体类里重写
toString()做脱敏，这会影响调试、测试、序列化等所有环节 - 应在日志输出前统一拦截：用 SafeException 包装器 对
e、e.getCause()、e.getSuppressed()逐层递归脱敏，把敏感字段值替换为[REDACTED] - 对 MDC 中注入的上下文（如
MDC.put("idCard", "110101199001011234")）也需清洗，Logback 可通过自定义Filter在日志事件生成前修改event.getMDCPropertyMap() - 禁用日志语句中拼接敏感值，例如
logger.error("用户 {} 登录失败，密码: {}", user.getName(), user.getPassword())→ 改为logger.error("用户 {} 登录失败", user.getName(), e)
简化：聚焦关键帧，跳过框架噪音
默认堆栈动辄百行，大量是 Spring、Netty、JDBC 驱动内部调用，真正业务代码可能只占几行。简化目标是保留“谁调用、在哪出错、为什么失败”的线索，去掉干扰项。
- Logback 可配置
%ex{full, 5}限制堆栈深度；或用%ex{short}自动省略java.lang.*、org.springframework.*等常见框架包路径 - 更精准的做法是自定义
ThrowableRenderer，过滤掉满足以下任一条件的堆栈帧：
• 类名以$$EnhancerBySpringCGLIB、$$FastClassBySpringCGLIB开头
• 方法名是invoke、doFilter、process等泛型入口
• 所在类属于已知中间件包（如io.netty.、com.zaxxer.hikari.） - 避免手动截断堆栈字符串（如
e.toString().substring(0, 200)），这会破坏异常链结构，导致getRootCause()失效
结构化输出：让脱敏和简化结果可检索、可关联
脱敏和简化后的堆栈仍要保留在结构化日志中，不能变成纯文本摘要。否则就失去了按异常类型聚合、按 traceId 关联链路的能力。
立即学习“Java免费学习笔记（深入）”；
- 使用 JSON Layout（如 Logback 的
ch.qos.logback.contrib.json.classic.JsonLayout），将脱敏后的message、清理过的stack_trace、traceId、userId等作为独立字段输出 - 确保
stack_trace字段内容仍为标准格式（含类名、方法、行号），只是其中变量值已被替换、部分帧已被跳过 - 在日志系统（如 ELK、Loki）中配置解析规则，把
stack_trace字段设为text类型并启用行内高亮，方便快速定位Caused by:和at com.yourpackage.
特别注意 suppressed 异常和嵌套 cause 的处理
Java 7+ 的 try-with-resources 会把多个异常合并，getSuppressed() 返回被压制的异常列表；Spring 等框架也可能包装异常形成多层 cause。这些若未脱敏简化，最容易成为信息泄露盲区。
- 必须对
e.getSuppressed()数组中每个Throwable单独执行脱敏 + 简化流程，不能只处理顶层异常 - 对
e.getCause()递归处理，直到cause == null；推荐用 Apache Commons Lang 的ExceptionUtils.getThrowableList(e)获取完整异常链再统一处理 - 在日志中明确标记 suppressed 异常，例如：
WARN Suppressed exception in resource cleanup: [REDACTED]，避免被忽略
