Java异常是诊断书，需先定位堆栈第一行真实出错点（如at com.example.UserDao.findById(UserDao.java:42)），再自底向上分析调用链，区分Runtime与Checked异常处理策略，并结合变量实际状态验证根因。
看到异常堆栈别急着改代码，先读懂它在说什么——Java异常本身不是问题，而是程序主动递来的诊断书。关键在怎么读、怎么拆、怎么验证。
盯紧堆栈第一行：定位真实出错点
异常信息最上面那行（比如 java.lang.NullPointerException）是类型，第二行（at com.example.UserDao.findById(UserDao.java:42)）才是关键：它明确告诉你哪类异常、在哪一个类的哪一行触发。很多人忽略这一行，转头去查调用它的上层方法，结果绕远路。注意看路径是否指向你自己的代码；如果是JDK或框架内部（如 at java.util.ArrayList.get(ArrayList.java:435)），说明问题出在你传给它的参数上。
顺藤摸瓜看调用链：从底向上还原现场
堆栈往下读，就是方法调用顺序：最底下是main或线程入口，越往上越接近出事现场。重点关注你写的类和方法名，跳过纯JDK/第三方包的中间层。例如：
- at com.example.UserService.getUser(UserService.java:67)
- at com.example.UserController.handleRequest(UserController.java:33)
说明是控制器调了服务，服务里第67行炸了。这时回到 UserService.java 第67行，检查那一行用了哪个对象、哪个数组、哪个参数——它大概率就是null、越界或类型不对的源头。
立即学习“Java免费学习笔记（深入）”；
分清异常性质：Runtime 还是 Checked？该捕还是该修？
NullPointerException、ArrayIndexOutOfBoundsException 这类 RuntimeException 是逻辑漏洞，不能靠 try-catch 掩盖，必须修复代码缺陷。而 IOException、SQLException 这类受检异常，编译器强制你处理，但别无脑加 catch + printStackTrace；要区分场景：文件读不到是提示用户重试，数据库连不上得告警+降级。错误做法是把所有异常都吞掉或只打日志不响应；正确做法是按异常语义做对应动作——恢复、重试、拒绝、兜底。
结合变量状态验证猜想：别只看代码，要看值
光读堆栈容易误判。比如报 ArrayIndexOutOfBoundsException，你以为是循环写错了，实际可能是数组根本没初始化成功，长度为0。这时候要用调试器停在出错行前，看数组变量是不是 null、length 是多少、索引变量算出来是几。或者加一行日志：log.debug("arr.length={}, index={}", arr == null ? "null" : arr.length, i);。对 null 值也一样：不是“if (obj != null) 就安全”，要确认 obj 是谁给的、什么时候变 null 的、有没有被并发修改。
