最直接方式是调用Exception对象的printStackTrace()方法，默认输出到System.err；开发阶段适用，但生产环境应使用Logger（如logger.error("msg", e)）以支持分级、异步等能力。
如何用 printStackTrace() 快速输出异常堆栈
最直接的方式就是调用 Exception 对象的 printStackTrace() 方法，它会把完整堆栈输出到 System.err。适合开发阶段快速定位问题，但不适合生产环境——因为无法控制输出目标，也不便于日志聚合。
常见错误是只打印了异常消息（e.getMessage()），结果看不到哪一行出的错、调用链路是什么。比如：
catch (IOException e) {
System.out.println("出错了：" + e.getMessage()); // ❌ 只有提示，没堆栈
}
正确做法是：
catch (IOException e) {
e.printStackTrace(); // ✅ 默认输出到 stderr
// 或指定输出流：e.printStackTrace(System.out);
}
为什么推荐用 Logger 而不是 printStackTrace() 上生产
printStackTrace() 无法被日志框架捕获和分级管理，且不支持异步、采样、脱敏等能力。SLF4J / Log4j 等主流日志器都提供带 Throwable 参数的重载方法，能自动展开堆栈。
立即学习“Java免费学习笔记（深入）”；
-
logger.error("文件读取失败", e);—— 推荐，堆栈自动附加 -
logger.error("文件读取失败: {}", e.getMessage(), e);—— 冗余，e已含消息 -
logger.error("文件读取失败", e.getCause());—— 错误，丢掉了原始异常本身
注意：如果用了 logback，确保 %ex 或 %xEx 在日志 pattern 中启用，否则堆栈不会显示。
getStackTrace() 和 fillInStackTrace() 的实际用途
getStackTrace() 返回 StackTraceElement[]，可用于自定义格式化或过滤敏感路径（如跳过 JDK 内部调用）；fillInStackTrace() 则用于手动重建堆栈，多见于异常包装场景。
例如在封装异常时避免堆栈丢失：
public class BusinessException extends RuntimeException {
public BusinessException(String msg, Throwable cause) {
super(msg, cause);
// 不需要手动 fillInStackTrace() —— 构造器已调用
}
}
// 但若想“重置”堆栈（极少见），可：
throw new RuntimeException().fillInStackTrace();
多数情况下你不需要碰这两个方法，除非写框架或做 AOP 异常拦截。
IDEA / VS Code 中怎么看堆栈更高效
不要只盯着控制台滚动日志。现代 IDE 支持点击堆栈行跳转到源码，前提是：
- 类有对应源码或已配置
source attachment - 编译时未开启
-g:none（即保留调试信息） - 不是
ClassNotFoundException这类类加载期异常（此时还没进方法体，堆栈天然短）
遇到 Caused by: 嵌套异常时，从最末尾的 Caused by 往上读——那才是根本原因。很多人习惯从第一行开始看，反而被包装异常带偏。
堆栈里出现 Native Method 或 Unknown Source 通常说明用了 JNI 或混淆/裁剪工具（如 ProGuard、R8），这时候得结合符号表或 map 文件还原。
