java中记录完整异常堆栈的关键是使用logger.error(msg, throwable)方法，避免tostring()截断、不吞异常、配置日志框架正确输出%ex，并在包装异常时传入原异常作为cause。
Java 中通过日志框架记录完整的异常堆栈信息，关键在于**不吞掉异常、使用支持 Throwable 的日志方法、避免 toString() 截断**。
用 logger.error(msg, throwable) 记录完整堆栈
这是最标准、最可靠的方式。主流日志框架（Logback、Log4j2、SLF4J 绑定实现）都支持在日志方法中直接传入 Throwable 对象，框架会自动打印完整堆栈跟踪（包括 cause chain）。
- ✅ 正确写法（推荐）：
logger.error("数据库查询失败", e);
这会输出错误消息 + 完整堆栈（含嵌套异常的 getCause() 链） - ❌ 错误写法：
logger.error("数据库查询失败: " + e);
这只调用了 e.toString()，丢失堆栈和 cause 信息 - ❌ 更隐蔽的错误：
logger.error("数据库查询失败", e.getMessage());
把异常消息当参数传，e 被忽略，堆栈完全不输出
确保日志配置启用 DEBUG/ERROR 级别且不截断
即使代码写对了，日志框架配置不当也会导致堆栈被省略或不输出：
- 检查 logback.xml 或 log4j2.xml 中 root logger 级别是否 ≥ ERROR（如
<root level="ERROR"></root>） - 确认 appender（如 ConsoleAppender、RollingFileAppender）未设置
maxHistory或maxFileSize导致旧日志被覆盖而丢失关键错误上下文 - Logback 中避免使用
%m单独占位符——它只输出消息；应使用%ex或默认模板（如%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n%ex），其中%ex显式渲染异常堆栈
捕获异常后不要“静默吞掉”再空抛
常见反模式：捕获异常 → 记录但不带 Throwable → 再 throw，导致原始堆栈丢失。
- ⚠️ 危险写法：
try { ... } catch (SQLException e) { logger.error("DAO 执行出错: " + e.getMessage()); // ❌ 堆栈丢失 throw new ServiceException("业务操作失败"); // ❌ 新异常无原始堆栈 } - ✅ 改进方式（保留根源）：
try { ... } catch (SQLException e) { logger.error("DAO 执行出错", e); // ✅ 完整记录 throw new ServiceException("业务操作失败", e); // ✅ 包装并保留 cause }
自定义日志工具类时注意 Throwable 参数透传
如果封装了日志工具方法（如 LogUtil.error(...)），必须显式接收 Throwable 并透传给底层 logger：
- ✅ 正确签名：
public static void error(String msg, Throwable t) { logger.error(msg, t); } - ❌ 错误签名：
public static void error(String msg, String reason) { logger.error(msg + ": " + reason); }
无法处理堆栈，也不支持 cause 链
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
