应直接将异常对象作为最后一个参数传入SLF4J日志方法，如logger.error("文件读取失败，路径：{}", filePath, e)，SLF4J会自动输出完整堆栈及嵌套异常，避免printStackTrace()或字符串拼接。
在 Java 异常处理中，用 SLF4J（配合 Logback）记录完整堆栈信息，关键在于**直接传入异常对象作为参数，而不是调用 printStackTrace() 或手动拼接字符串**。SLF4J 会自动捕获并格式化整个堆栈跟踪，这是最简洁、可靠且符合日志规范的做法。
正确写法：把异常对象作为最后一个参数传入
SLF4J 的日志方法（如 error()、warn()）支持可变参数，当最后一个参数是 Throwable 类型时，框架会自动将其识别为异常，并在日志中输出完整的堆栈信息。
- ✅ 推荐（清晰、完整、无额外代码）：
try {
// 可能抛异常的代码
riskyOperation();
} catch (IOException e) {
logger.error("文件读取失败，路径：{}", filePath, e); // e 是最后一个参数
}这样输出的日志包含：时间、级别、消息（含变量值）、换行分隔的完整堆栈，Logback 默认格式下可直接定位根因。
避免常见错误写法
以下方式会丢失堆栈或造成冗余，应避免：
立即学习“Java免费学习笔记（深入）”；
-
❌ 手动调用
e.printStackTrace()：输出到控制台而非日志系统，无法集中管理、搜索和告警； -
❌ 拼接字符串：
"异常：" + e.toString()或e.getMessage()：只记录简短信息，丢失堆栈、类名、行号、嵌套异常等关键线索； -
❌ 把异常放在非末位：
logger.error(e, "出错了")：SLF4J 不识别，e 被当成普通 Object，仅打印toString()，堆栈丢失。
处理嵌套异常（Caused by）也无需额外操作
如果异常本身包含 cause（比如 new RuntimeException("业务失败", originalException)），SLF4J + Logback 默认会递归展开所有 getCause()，完整打印 “Caused by” 链。你只需照常传入最外层异常即可：
catch (ServiceException e) {
logger.error("订单创建失败，用户ID：{}", userId, e); // 自动展开所有嵌套
}进阶建议：结合 MDC 增强上下文
在分布式或高并发场景，可在 try 块开始前用 MDC（Mapped Diagnostic Context）注入追踪 ID、用户 ID 等字段，让异常日志自带上下文，便于问题定位：
MDC.put("traceId", UUID.randomUUID().toString());
MDC.put("userId", currentUser.getId());
try {
processOrder();
} catch (Exception e) {
logger.error("订单处理异常", e); // 日志自动带上 traceId 和 userId
} finally {
MDC.clear();
}需确保 Logback 配置中 pattern 包含 %X{traceId} 等占位符，例如：<pattern>%d{HH:mm:ss.SSS} [%X{traceId}] [%thread] %-5level %logger{36} - %msg%n</pattern>
