真正出问题的地方是异常堆栈最上面那行（Caused by后第一行），即at com.example.XxxService.doSomething(XxxService.java:42)这类具体文件和行号，但需注意它未必是逻辑根源，可能由上游未初始化等导致。
异常堆栈里哪一行才是真正出问题的地方
Java异常抛出时打印的堆栈，最上面那行（Caused by 后的第一行）通常是**真正触发异常的代码位置**，但要注意：它不一定是逻辑错误的根源。比如 NullPointerException 显示在 user.getName() 报错，问题可能出在 user 上层未初始化，而非 getName() 方法本身有 bug。
实操建议：
- 优先检查堆栈顶部的
at com.example.XxxService.doSomething(XxxService.java:42)这类行，定位到具体文件和行号 - 如果该行是 JDK 或框架调用（如
at java.util.ArrayList.get(ArrayList.java:425)），说明你传入了非法参数（比如 index 越界），要回溯你自己的调用点 - 注意
Suppressed和Caused by的嵌套层级——底层异常（如 IO 异常）可能被上层封装成RuntimeException，需逐层展开看原始 cause
为什么 try-catch 吞掉异常后问题更难查
用空的 catch 块或只打一句 log.error("出错了") 会丢失关键上下文，等于把报错现场直接抹掉。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
正确做法：
- 绝不用
catch (Exception e) { }—— 至少要logger.error("处理订单失败，orderId={}", orderId, e) - 记录关键业务变量（如
userId、requestId），方便关联链路追踪 - 必要时在 catch 中重新抛出带上下文的异常：
throw new ServiceException("更新库存失败，skuId=" + skuId, e)
如何用 IDE 快速跳转到异常抛出处（非断点）
不是所有问题都适合打断点——尤其线上复现难、或异常发生在第三方库内部时，靠 IDE 的「异常断点」比手动加断点高效得多。
以 IntelliJ IDEA 为例：
- 打开
Run → View Breakpoints（快捷键Ctrl+Shift+F8） - 点击
+→Java Exception Breakpoint，输入异常类名，如NullPointerException - 勾选
On caught exception（捕获时停）或On uncaught exception（未捕获时停），后者更常用 - 运行程序，一旦抛出该异常，IDE 自动停在
throw那一行，而不是 catch 处
注意：不要对泛型异常（如 Exception）全局启用，会频繁中断；应聚焦具体异常类型，比如排查 NumberFormatException 时才设它。
自定义异常时哪些字段真有用
很多团队定义的 BusinessException 只有 message 和 code，但排错时真正需要的是可追溯的上下文。
推荐至少包含：
-
errorCode：字符串格式错误码（如"ORDER_PAY_TIMEOUT"），别用纯数字，避免跨服务含义冲突 -
requestId：当前请求唯一 ID，用于日志串联 -
detailMessage：面向开发者的详细描述（含变量值，如"库存不足，expected=5, actual=2, skuId=1001"） - 保留原始
cause，别用super(message)简单构造
示例：
public class InventoryException extends RuntimeException {
private final String errorCode;
private final String requestId;
public InventoryException(String errorCode, String requestId, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
this.requestId = requestId;
}
}
复杂点在于：异常对象本身不该承担日志输出职责，但它的字段必须让日志框架能一键提取关键信息。漏掉 requestId 或 detailMessage，等于把排错成本又推回人工 grep 日志。
