Java异常调试需快速定位源头、分清异常类型、验证修复效果：通过堆栈锁定出错位置，区分checked/unckecked异常及Error，本地复现+断点调试，结合日志与APM监控。
Java异常调试不是靠猜，而是有章法的——重点在快速定位源头、分清异常类型、验证修复效果。
看懂异常堆栈，5秒锁定出错位置
每次异常抛出，控制台第一行就是关键线索：
- “Exception in thread 'main' java.lang.NullPointerException” → 表明是空指针，且发生在主线程
- “at com.example.UserDao.findById(UserDao.java:27)” → 精确到类、方法、第27行
- 堆栈从下往上读：最底行是调用起点，最顶行才是实际抛出点
别跳过caused by：嵌套异常（如SQLException包裹着IOException）往往藏着真正病因。
区分三类异常，决定怎么处理
不是所有异常都该catch，处理方式取决于它的性质：
立即学习“Java免费学习笔记（深入）”；
- 检查型异常（Checked）：如IOException、SQLException。编译器强制你处理——要么try-catch，要么用throws声明上抛
- 非检查型异常（Unchecked）：如NullPointerException、ArrayIndexOutOfBoundsException。属于逻辑错误，优先改代码，而非掩盖它
- 错误（Error）：如OutOfMemoryError、StackOverflowError。通常不捕获，要查内存配置、递归深度或JVM参数
本地复现+断点调试，比日志更直接
线上报错？先在本地用相同参数复现。然后：
- 在疑似出问题的前一行打断点（IDE里点击行号左侧空白处）
- 用Debug模式运行，停住后看Variables面板：哪个变量是null？集合size是不是0？数组length是否小于索引？
- F6单步跳过（执行当前行），F5单步进入（钻进方法内部），快速验证执行路径
对空指针高频场景，可提前加防护：Objects.requireNonNull(obj, "user不能为空")，让问题暴露得更早、更明确。
日志+监控，让异常不再“突然出现”
生产环境不能只靠堆栈，要让异常行为可追溯：
- 在catch块里记录ERROR日志，带上关键变量值和上下文ID（如traceId）
- 对可能为空的对象，在使用前加DEBUG日志：“userId = {}”，避免事后翻日志找不到输入值
- 接入APM工具（如SkyWalking），自动捕获未处理异常并关联请求链路
基本上就这些。不复杂但容易忽略——堆栈要看全、类型要分清、本地要复现、日志要留痕。
