slf4j需将异常对象作为最后一个参数传入日志方法才能正确输出完整堆栈，否则会丢失cause chain和suppressed异常；结构化日志中应结合mdc元数据与%ex格式化，生产环境需脱敏并控制堆栈行数，异步日志须确保异常可序列化。
SLF4J 日志中正确输出异常堆栈
SLF4J 本身不处理异常序列化，而是依赖底层日志框架（如 Logback、Log4j2）来格式化并输出堆栈。关键在于：**必须将异常对象作为最后一个参数传入日志方法，不能 toString() 或拼接进字符串**。
✅ 正确写法：
log.error("用户登录失败，用户名：{}", username, e);
❌ 错误写法（堆栈丢失）：
log.error("用户登录失败，用户名：{}，异常：{}", username, e.toString()); // 堆栈被截断为单行
log.error("用户登录失败，用户名：" + username + "，异常：" + e); // 同样丢失完整堆栈
这样写，SLF4J 会识别 e 是 Throwable 类型，交由日志实现自动展开多行堆栈，包含 cause chain 和 suppressed 异常（Java 7+）。
自定义异常序列化以适配结构化日志
当使用 JSON 日志（如 Logback 的 JsonLayout 或 Log4j2 的 JsonLayout）时，原始堆栈会被扁平化成字符串，不利于 ELK 等系统解析。此时需控制堆栈的序列化方式：
- 在 Logback 中，可通过自定义
ThrowableProxyConverter或使用logback-access提供的%ex{full}等格式化选项增强可读性 - 更推荐做法：用 MDC 记录关键异常元数据，例如：
MDC.put("exc_class", e.getClass().getName());<br>MDC.put("exc_message", e.getMessage());<br>MDC.put("exc_trace_id", UUID.randomUUID().toString());
再配合日志框架的 JSON 字段映射，让堆栈主干仍走%ex，元信息独立成字段，便于过滤与聚合
避免敏感信息泄露的堆栈脱敏策略
生产环境堆栈可能含路径、参数、数据库连接串等敏感内容。SLF4J 无法自动脱敏，需主动干预：
- 对特定异常类型（如
SQLException、HttpClientErrorException）重写getStackTrace()或包装为自定义异常，过滤掉toString()中的敏感字段 - 在日志配置中启用堆栈裁剪（Logback 示例）：
<encoder><br><pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%ex{10}</pattern><br></encoder>
其中{10}表示最多打印 10 行堆栈，减少冗余和风险 - 借助 AOP 或全局异常处理器，在记录前调用工具类清洗堆栈字符串（如正则替换密码、token、IP 等），但注意性能开销
异步日志场景下的异常处理注意事项
使用异步 Appender（如 Logback 的 AsyncAppender）时，异常对象若含线程局部变量（如未序列化的 ThreadLocal 引用）、代理对象或 NIO Buffer，可能导致序列化失败或日志丢失：
- 确保异常类及其所有字段可序列化（实现
Serializable），尤其自定义异常要显式定义serialVersionUID - 避免在异常构造时直接捕获并持有非序列化上下文对象；改用延迟计算或只存 ID/摘要
- 测试异步日志是否真能输出堆栈：抛出异常后检查日志文件，确认不是空行或 “java.lang.NullPointerException” 而无 trace
