Java异常日志堆栈冗长主因是Spring AOP、CGLIB代理等框架层帧，应通过提取根因、包名过滤和结构化输出精简：用ExceptionUtils.getRootCause获取原始异常，截取关键堆栈行，配置Logback/Log4j2按包过滤，结构化记录字段并截断消息长度，对InterruptedException等无价值异常类型级压缩。
Java异常日志里堆栈太长，主要不是因为业务代码深，而是Spring AOP、CGLIB代理、JDK反射调用等框架层帧大量挤占空间。真正需要定位问题的，往往只是最外层异常、根因（root cause）和几行关键业务调用。过滤掉冗余框架堆栈，核心是“主动提取 + 包名过滤 + 结构化输出”，而不是依赖默认打印。
提取根本原因，跳过层层包装
多数异常被Spring、MyBatis或RPC框架多次包装（如InvocationTargetException → SQLException → DataAccessException），直接打印完整链路信息量大且干扰强。
- 用Apache Commons Lang的ExceptionUtils.getRootCause(e)获取最底层原始异常，例如数据库连接失败的真实SQLException
- 配合ExceptionUtils.getStackTrace(e)拿到字符串堆栈后，用流操作截取前3行（异常类型+消息）和后5行（实际出错位置），跳过中间数百行CGLIB、proxy$、ReflectiveMethodInvocation等无关帧
- 避免在日志中写
logger.error("xxx", e)就完事——这会原样展开整个嵌套链；改为先处理再记录
配置日志框架，按包名排除干扰类
Logback 和 Log4j2 都支持在堆栈渲染阶段直接过滤特定包路径，这是生产环境最稳定、侵入性最小的方式。
- Logback中使用ShortenedThrowableConverter，在
logback-spring.xml里添加：
<throwableConverter class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
<exclude>org.springframework.cglib</exclude>
<exclude>com.sun.proxy</exclude>
<exclude>org.springframework.aop</exclude>
</throwableConverter>
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- Log4j2可在
PatternLayout中用%throwable{full, 5}限制总深度，再配合RegexFilter对日志事件内容做二次匹配过滤 - 自定义ThrowableProxyConverter子类，在
convert()里遍历getStackTraceElement()，跳过含"$$EnhancerBySpringCGLIB"或"proxy$"的帧
结构化记录，把异常拆成字段而非一整段message
把异常对象toString()后塞进%msg，等于把所有代理类全限定名、内部状态都打包进去，既难读又易泄露敏感信息。
- 用MDC单独注入
traceId、interfaceName等上下文，不和异常混在一条日志里 - 日志模板显式控制字段：
logger.error("db_fail|code={},root={}|msg={}", errorCode, root.getClass().getSimpleName(), StringUtils.substring(root.getMessage(), 0, 120)) - 对
e.getMessage()做长度截断，防止某条超长SQL或token撑爆单行日志
对高频无意义异常做类型级精简
像InterruptedException、TimeoutException这类系统级异常，堆栈通常无助于定位，反而刷屏。
- 写一个轻量ThrowableConverter，继承
ch.qos.logback.classic.pattern.ThrowableProxyConverter - 在
convert()中判断throwableProxy.getClassName()是否为黑名单类型 - 匹配时只返回
className + ": " + message，完全跳过堆栈生成逻辑 - 比全局
%ex{1}更精细：保留业务异常的完整堆栈，仅压缩已知无价值类型
