结论：定位问题必须依赖完整的堆栈轨迹；printStackTrace() 展示异常类型、消息、抛出点及完整调用链，而 getMessage() 常为空且无上下文，日志应使用 log.error(msg, t) 记录全栈，遇包装异常需递归 getCause() 挖掘根源。
直接说结论：用 printStackTrace() 看全貌，用 getMessage() 取简短原因，但真正定位问题得靠完整的堆栈轨迹——它不是“附带信息”，而是唯一能告诉你「谁在什么时候、哪一行、调用了什么方法」的证据。
为什么 getMessage() 经常返回空或没用
它只返回异常构造时传入的字符串，很多标准异常（比如 NullPointerException、ArrayIndexOutOfBoundsException）默认不带消息，所以调用 e.getMessage() 得到 null 或空字符串很常见。
- 不是所有异常都主动设置消息，尤其是运行时异常
- 即使有消息，也往往不含行号、类名、调用链等关键上下文
- 日志里只记
getMessage()，等于把医生只告诉“你病了”，却不给体温和CT片
printStackTrace() 的输出到底包含哪些关键层
它的标准输出是三层结构：异常类型 + 消息 → 当前抛出点（文件+行号）→ 逐层向上回溯的调用路径。每一行都对应一个 StackTraceElement。
- 第一行是异常类名和
getMessage()内容（如果有） - 第二行起是
at com.example.Service.handle(UserService.java:42)这类格式，其中UserService.java:42是真·问题发生位置 - 最上面那个
at行才是异常源头；下面的都是“谁调了谁”——别看反了 - 如果在 IDE 控制台里看到省略号（
... 12 more），说明有重复调用帧被折叠，需用e.getStackTrace()全量读取
生产环境不能直接用 printStackTrace() 到控制台
它默认输出到 System.err，而生产系统通常没有控制台，且无法被日志框架捕获、归档或告警。
- 应该用日志框架的
error(String msg, Throwable t)方法，例如log.error("处理订单失败", e) - Logback / Log4j 会自动提取并格式化整个堆栈，比手动
printStackTrace()更可靠 - 若必须手动拼装，用
Arrays.toString(e.getStackTrace())获取原始数组，再按需截断或过滤（比如去掉 JDK 内部类） - 注意：
e.toString()只是类名+消息，不含堆栈；别把它和printStackTrace()搞混
堆栈轨迹里最易被忽略的是「异常包装」：比如 SQLException 被包进 RuntimeException，再被包进 WebException。只看最外层的类名和消息，可能永远找不到数据库连接超时的根源——得一层层调用 e.getCause() 往下挖。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
