根本原因是log.error("msg " + e)将异常转为字符串，仅保留类名和message而丢失堆栈；正确写法是log.error("msg", e)，使logback识别throwable参数并自动打印完整堆栈。
Logback 中写成 log.error("msg " + e) 会导致堆栈信息丢失，根本原因是：这行代码把异常对象 e 转成了字符串（调用 e.toString()），只保留了异常类名和 message，而完整的堆栈跟踪（stack trace）根本没有传给 Logback 的日志方法。
确认是否真的丢了堆栈
检查实际输出的日志内容：
- 如果只有类似
ERROR ... msg java.lang.NullPointerException: null，没有多行的at xxx.xxx.xxx，说明堆栈已丢失； - 如果日志里有完整的异常调用链，那问题不在这里，需查配置或异步日志等其他原因。
正确写法：把异常对象作为最后一个参数传入
Logback（以及 SLF4J）约定：当方法签名末尾是 Throwable 类型参数时，框架会自动提取并打印完整堆栈。必须保持这个结构：
- ✅ 正确：
log.error("msg", e); - ✅ 正确（带格式化）：
log.error("user {} failed with code {}", userId, errorCode, e); - ❌ 错误：
log.error("msg " + e);（e 被 toString()，堆栈丢弃） - ❌ 错误：
log.error("msg", e.toString());（传的是字符串，不是 Throwable）
检查日志配置是否禁用了堆栈输出
即使代码写对了，Logback 配置也可能过滤掉堆栈。重点看 <encoder></encoder> 或 <layout></layout> 中是否用了自定义 Pattern，尤其是：
- 避免使用
%ex、%xEx、%throwable以外的占位符来“手动拼接”异常（比如用%m拼接后加e.toString()）； - 确认 pattern 包含
%ex（推荐）或%xEx（带上下文），例如：%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n%ex； - 若用了
AsyncAppender，确保其includeCallerData或异常处理逻辑未被覆盖（默认不影响堆栈打印）。
排查工具与辅助手段
快速验证当前行为：
- 在本地写个最小复现：
try { throw new RuntimeException("test"); } catch (Exception e) { log.error("boom", e); }，观察控制台/文件输出是否有堆栈； - 开启 SLF4J 绑定检测：启动时加 JVM 参数
-Dslf4j.detectLoggerNameMismatch=true，可捕获部分绑定异常； - 临时改用
log.error("msg", e.getCause() != null ? e.getCause() : e);排查是否因嵌套异常导致显示不全（但通常不是主因）。
不复杂但容易忽略：异常堆栈不是“自动附带”的，它依赖 SLF4J 的参数类型识别机制。只要保证 Throwable 是独立参数、且配置中启用了 %ex，就能稳定输出完整堆栈。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
