printStackTrace() 输出数百行是因为JVM完整记录调用路径，含Spring AOP、CGLIB等代理帧；应改用getStackTrace()过滤业务包如"com.yourcompany"，结合类名、文件名和行号精准定位问题代码。
为什么 printStackTrace() 一跑就是几百行
Java 异常栈默认会把所有调用帧都打出来，包括 Spring AOP 代理、CGLIB 字节码增强、Servlet 容器过滤链、线程池包装类……真正属于你写的业务代码可能就夹在中间两三行里。这不是 JVM 的 bug，是它“尽职尽责”地记录了整个调用路径——但你只想知道 UserService.java:42 这一行到底出了啥问题。
用 Throwable.getStackTrace() 手动筛出业务包路径
别依赖 e.printStackTrace() 直接输出，改用 getStackTrace() 拿到原始数组，自己过滤。重点不是“去掉多少行”，而是“只留哪些包”。
常见做法：
- 白名单方式：只保留包含
"com.yourcompany"或"cn.yourproject"的栈帧 - 黑名单方式：跳过
"org.springframework."、"javax.servlet."、"java.util.concurrent."等高频干扰包 - 优先匹配
className.contains("Service") || className.contains("Controller")，快速定位入口类
示例（简化版）：
立即学习“Java免费学习笔记（深入）”；
for (StackTraceElement e : exception.getStackTrace()) {
String cn = e.getClassName();
if (cn.startsWith("com.example.") && !cn.contains("$$EnhancerBySpringCGLIB")) {
System.err.println(e);
break; // 找到第一个就停，通常就是你写的那行
}
}
IDE 调试时怎么秒跳到业务代码行
IntelliJ 和 Eclipse 都支持「异常断点 + 栈帧折叠」，但默认不生效。关键设置有两处：
- 在 Breakpoints 设置里勾选
Include library frames→ 改成 取消勾选，否则调试器会把你拖进 Spring 源码里绕圈 - 右键调用栈 →
Hide Frames from Libraries，立刻收掉所有第三方包帧 - 如果用了 Lombok，确保
@Slf4j日志里没用log.error("msg", e)直接传异常——这会触发完整栈打印；改用log.error("failed to process order {}", orderId, e)，Logback 默认会压缩栈
生产环境日志里栈太长影响排查效率
Logback / Log4j2 默认不压缩栈，但可以配 %ex{short} 或 %xEx{1} 控制深度。不过更可靠的是自定义 ThrowableRenderer：
-
%ex{full}→ 全量（慎用） -
%ex{short}→ 只留最外层异常 + 第一个业务类帧（推荐） -
%ex{rootFirst}→ 把 root cause 放最前，适合嵌套异常场景 - 如果用了 Sentry 或 ELK，注意它们自带栈解析逻辑，可能覆盖你的日志配置，得去对应平台看「stack trace」的「fingerprinting」规则
真正麻烦的不是栈长，是同一段业务代码被多个代理层层包裹后，getClassName() 返回的不是你源码里的类名，而是 UserServiceImpl$$EnhancerBySpringCGLIB$$a1b2c3d4 ——这时候得结合 getFileName() 和 getLineNumber() 判断，它们通常还是准的。
