异常类型后的消息才是关键线索，如“Cannot invoke 'String.length()' because 'name' is null”直接指出问题对象和操作；需优先定位自己代码中符合包名、.java 文件、可跳转行号的 at 行。
看懂堆栈第一行：异常类型 + 消息才是关键线索
别急着往下翻 at 行。java.lang.NullPointerException 这类异常类型只告诉你“哪类命格出了问题”，真正决定你该修哪一行的，是它后面的异常消息，比如 Cannot invoke "String.length()" because "name" is null。JDK 14+ 默认开启详细 NPE 描述，它直接点名了出问题的对象（name）和动作（String.length()）。老版本 JDK（如 8、11）可能只输出空消息，这时你就得依赖后续栈帧里的行号反推——但前提是堆栈没被 JVM 优化掉。
找属于你自己的那一行 at：过滤框架/中间件干扰
堆栈里往往混着大量 at org.springframework...、at java.base/java.lang.reflect... 这类调用，它们只是“通道”，不是“现场”。你应该从上往下扫，找第一个符合以下全部条件的 at 行：
- 包名是你自己项目代码的（比如
com.yourcompany.order、cn.xxx.service） - 文件名以
.java结尾，且路径真实存在（不是GeneratedMethodAccessor或Proxy） - 行号可点击跳转（IDE 中能 Ctrl+Click 进去）
如果找不到这样的行，有两种可能：一是异常发生在字节码增强阶段（如 Lombok、MyBatis-Plus 的代理方法），二是堆栈被 JVM 优化裁剪了（见下一条）。
警惕堆栈丢失：高频异常触发 JVM 的“懒加载堆栈”机制
OpenJDK（尤其是 HotSpot）对频繁抛出的相同异常会做栈帧省略优化。典型表现是日志里只看到 java.lang.NullPointerException，后面没有 at 行，或者 e.getStackTrace().length == 0。这不是日志配置问题，而是 JVM 主动行为：
- 触发条件：同一异常类在极短时间内（毫秒级）重复抛出数十次以上
- 影响范围：仅限于异常对象的
getStackTrace()返回值，不影响printStackTrace()的控制台输出（但部分日志框架会自行截断） - 绕过方式：加 JVM 参数
-XX:-OmitStackTraceInFastThrow（OpenJDK 8u292+ / 11+ 默认启用该优化）
这个参数必须加在启动命令最前面，且不能被其他配置覆盖；线上环境慎用，它会略微增加异常创建开销。
当 at 行指向桥接方法或 lambda：还原真实源码位置
泛型擦除、lambda 表达式、接口默认方法都可能导致 at 行显示的类/方法名与你写的源码不一致。例如：
at com.example.UserService.lambda$save$1(UserService.java:42) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
这时要盯住 lambda$save$1 这种命名——它说明该栈帧来自 UserService.save 方法内的某个 lambda。打开 UserService.java 第 42 行附近，找 stream().map(...) 或 forEach(...) 这类结构。同理，$jacoco、$$_beanFactory 等后缀也指向字节码插桩或 Spring CGLIB 代理，真实逻辑仍在原始方法体内。
堆栈不是线性日志，它是执行路径的倒放录像。最容易被忽略的，是把“最上面的 at 行”当成根因——其实它只是最后一环；真正要抓的，是那个既在你代码包里、又带具体行号、还符合异常消息语义的栈帧。
