真正有用的堆栈行是前2–4行：首行为异常类型和消息，其次为Caused by链，再往下是首个业务代码行（如at com.example.service.UserService.createUser(UserService.java:42)），重点找自己包路径下的行。
异常堆栈里哪几行真正有用
Java异常抛出时打印的堆栈信息通常很长，但真正需要关注的只有最上面2–4行：第一行是异常类型和消息，接下来几行是Caused by链（如果有嵌套异常），再往下是最早触发异常的业务代码位置——也就是at com.example.service.UserService.createUser(UserService.java:42)这类带具体类名、方法名、行号的行。
常见误区是盯着at java.base/... 这种JDK内部调用看，其实它们只是执行路径，不是问题根源。重点找你自己的包路径（如com.yourcompany）下的那一行。
- 如果堆栈里没有你的代码行，说明异常发生在框架回调或代理中，得结合日志上下文或断点回溯
-
NullPointerException要先看报错行哪个变量是null，而不是直接查NPE定义 - Spring项目中常见
org.springframework.web.servlet.DispatcherServlet.doDispatch打头的堆栈，真正的业务入口往往在它下面第三、第四层
如何让异常自带上下文信息
直接抛new RuntimeException("xxx")等于扔掉线索。应该把关键业务状态塞进异常消息或使用带参数的构造函数。
比如数据库操作失败时，不要只写throw new ServiceException("保存失败")，而是：
立即学习“Java免费学习笔记（深入）”；
throw new ServiceException(
String.format("用户创建失败，手机号=%s，邮箱=%s", user.getPhone(), user.getEmail())
);
更进一步，可以封装工具方法：ExceptionUtils.wrap("订单提交异常", order.getId(), e)，自动附加ID、时间戳、线程名等。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 避免在日志里重复打印异常消息，否则会冗余（如
log.error("xxx", e)已含消息，再手动拼一次就多余） - 敏感字段（密码、身份证号）必须脱敏后再加入异常信息
- 自定义异常类建议重写
toString()，确保打印时包含必要上下文
IDE调试时怎么快速跳到异常源头
IntelliJ IDEA和Eclipse都支持“异常断点”（Exception Breakpoint），比普通行断点更高效。
设置方式：打开Breakpoints窗口 → 点+ → 选Java Exception Breakpoint → 输入NullPointerException或你的自定义异常类名。勾选On caught exception可捕获被try-catch处理过的异常。
- 慎用
Any Exception，会导致大量干扰中断，尤其在Spring启动阶段 - 运行时动态启用/禁用某个异常断点，比删改代码加
if (true) throw快得多 - 配合
Drop Frame功能，能退回上一层调用栈重新执行，适合复现偶发空指针
日志+异常组合排查的典型盲区
很多团队只依赖异常堆栈，却忽略日志时间线与异常之间的gap。比如一个TimeoutException发生前100ms，日志里可能有SQL执行耗时：892ms，但没人去查这条SQL。
关键动作是把异常和最近几条INFO/WARN日志对齐，尤其注意：
- 异常前最后一条日志是否含
traceId或requestId？这是串联全链路的唯一钥匙 - 是否有
WARN级日志提示连接池耗尽、缓存穿透、限流触发？它们常是后续异常的伏笔 - 异步任务（
@Async、线程池）抛出的异常默认不传播，也不会打在主请求日志里，得单独查对应线程的日志片段
线上环境别只盯着ERROR级别，有时WARN才是真正的起点，而ERROR只是结果。
