异常堆栈第一行指明异常类型，定位问题需看第二行的文件名和行号；Native Method或Unknown Source行应向上回溯至最近的自定义代码行；checked异常暴露未处理的I/O等失败，unchecked异常揭示空值或边界逻辑缺陷。
看懂异常堆栈的第一行
Java异常抛出时，控制台或日志里最顶上那行 Exception in thread "main" java.lang.NullPointerException 就是关键——它告诉你发生了什么异常，但不告诉你在哪。真正定位问题的位置，在紧接着的下一行，比如 at com.example.MyService.process(MyService.java:23)。这个 MyService.java:23 才是你要立刻打开、跳转、检查的地方。
常见误区是只盯着异常类型（如 NullPointerException）去猜逻辑，而忽略堆栈中明确标注的文件和行号。如果看到类似 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 这种带 Native Method 或 Unknown Source 的行，说明异常来自JDK内部反射、动态代理或已剥离调试信息的jar包，这时要往它上面最近一个你自己的类名+行号回溯。
区分 checked 和 unchecked 异常的调试意义
IOException、SQLException 这类 checked 异常必须显式处理（try-catch 或 throws），所以一旦抛出，基本能确定是业务逻辑中某次I/O失败未被妥善兜底；而 NullPointerException、ArrayIndexOutOfBoundsException 这类 unchecked 异常往往暴露的是空值传递、边界判断遗漏等更隐蔽的逻辑缺陷。
- 遇到
NullPointerException，不要急着加if (x != null)，先查堆栈定位到具体哪一行的哪个变量为null，再顺藤摸瓜看它的上游赋值路径（构造函数？方法返回？配置注入？） - 遇到
NumberFormatException，重点检查Integer.parseInt()或Long.valueOf()的输入来源——是不是前端传了空字符串、字母或带空格的数字？ - 日志中若出现
Caused by:块，务必从最底层的Caused by:往上看，根源通常在最后一层嵌套里。
用 IDE 快速跳转并验证异常上下文
IntelliJ IDEA 或 Eclipse 点击堆栈中的 MyService.java:23 可直接跳转。但光看那一行不够，要结合三件事快速验证：
立即学习“Java免费学习笔记（深入）”；
- 把光标停在报错行，调出“Evaluate Expression”（IDEA按
Alt+F8），手动执行可疑表达式，比如user.getName()看是否真为null - 在该行上方设断点，重新运行，观察局部变量面板里各对象的实际状态，尤其注意集合类（
list.size()是否为 0）、包装类型（Integer id是否为null） - 检查该方法的入参是否被外部误传了
null，可在方法入口加临时日志：log.debug("input user: {}", user);
注意：某些异常（如 ConcurrentModificationException）具有随机性，单步调试可能无法复现，这时得靠添加 Thread.dumpStack() 或改用 CopyOnWriteArrayList 等线程安全替代方案来缩小范围。
日志中没有完整堆栈？补全它
线上环境经常只打印异常类名和消息，比如 java.lang.RuntimeException: Failed to save user，缺少堆栈。这是因为捕获后仅调用了 e.getMessage() 而非 e.printStackTrace() 或 log.error("", e)。
修复方式很简单：
- 日志框架中，务必用占位符 + 异常对象：
log.error("Failed to save user, userId={}", userId, e);—— 第三个参数e会自动输出完整堆栈 - 如果只能用
System.out.println()临时调试，别写System.out.println(e)，改用e.printStackTrace() - Spring Boot 项目中，确保
application.properties没有误配logging.level.root=WARN导致ERROR级别日志被过滤
堆栈被截断或丢失，等于医生没看到化验单就开药——再熟练的开发者也难精准下手。
