logback 完整输出异常堆栈的关键是：直接将异常对象作为最后一个参数传入日志方法（如 error("msg", e)），并在 logback.xml 的 pattern 中配置 %ex 或 %xex；避免 tostring() 调用和异常吞没。
logback 默认会打印完整的异常堆栈，但实际开发中常因日志语句写法不当（如仅打印 e.tostring() 或 e.getmessage()）而丢失关键信息。要确保完整堆栈输出，核心在于：**直接传入异常对象作为参数，而非手动调用其方法**。
正确写法：把异常对象作为最后一个参数传入
Logback 的日志方法（如 error()、warn()、debug()）支持可变参数，当最后一个参数是 Throwable 类型时，框架会自动将其展开为完整堆栈跟踪，并格式化输出到日志中。
- ✅ 正确（打印完整堆栈）：
logger.error("数据库查询失败", e); - ❌ 错误（只打异常消息，无堆栈）：
logger.error("数据库查询失败: " + e.getMessage()); - ❌ 错误（堆栈变成字符串，格式混乱且不标准）：
logger.error("数据库查询失败", e.getStackTrace().toString());
检查 logback.xml 中的 pattern 是否保留 %ex 或 %xEx
即使代码传入了异常对象，若日志输出模板（%pattern）中未显式配置异常字段，堆栈仍可能被忽略。推荐在 PatternLayout 中包含以下任一占位符：
-
%ex：标准异常堆栈（最常用） -
%xEx：带嵌套异常展开的扩展版（适合有 cause 链的场景） -
%throwable：同%ex，语义更清晰
示例配置片段：
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"><encoder><pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%ex%n</pattern></encoder></appender>避免在 catch 块中“吞掉”异常或重复包装
常见错误是捕获异常后自行处理却未重新抛出，又未记录原始异常，导致上下文丢失：
- ⚠️ 危险写法（掩盖根源）：
catch (SQLException e) { logger.error("操作失败"); } - ✅ 改进方式（保留原始异常）：
catch (SQLException e) { logger.error("用户订单提交失败", e); } - ✅ 若需转换异常类型，仍应设为 cause：
throw new ServiceException("下单异常", e);→ 后续日志中传这个新异常，Logback 仍能递归打印e的堆栈
验证是否生效的小技巧
快速确认堆栈是否正常输出：
- 在测试代码中主动抛出一个带 cause 的异常，例如：
throw new RuntimeException("业务异常", new NullPointerException("空指针")); - 查看日志输出是否包含多层
Caused by:行 —— 有则说明%xEx生效且异常链完整传递 - 对比 IDEA 控制台与文件日志内容是否一致（有时控制台因宽度限制折叠堆栈，文件更可靠）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
