切面静默吞异常会导致异常传播链中断。需全局搜索@around中proceed()外的catch块，检查是否仅日志打印或返回兜底值而未重抛；推荐catch(throwable t)记录完整堆栈后throw t，并通过ci静态检查、默认异常处理器等机制预防。
确认切面是否静默吞掉了异常
很多问题的起点是：异常确实发生了，但被某个@Around切面用try-catch捕获后，既没记录完整堆栈，也没重新throw出去。这种“吞异常”行为会让全局异常处理器、监控系统、告警链路全部失效——调用方收到null或默认值，日志里只有业务成功痕迹，而错误早已在切面里被抹平。
检查方式很简单：
- 全局搜索项目中所有
@Around方法，重点看proceedingJoinPoint.proceed()外层是否有catch (Exception e)或更宽泛的catch (Throwable t) - 若存在catch块，检查里面是否只做了日志打印（如
log.info("xxx")）或返回了兜底值（如return null、return Collections.emptyList()），却漏掉throw e或throw new RuntimeException(e) - 特别注意：仅捕获
Exception会漏掉RuntimeException子类（比如NullPointerException、IllegalArgumentException），而catch (Throwable)又可能吞掉Error（如OutOfMemoryError），需按实际场景权衡
验证异常传播链是否中断
一个正常工作的异常流应该是：目标方法抛出 → 切面内proceed()原样穿透 → 切面自己决定捕获/增强/再抛 → 最终抵达全局@ExceptionHandler或线程未捕获处理器。只要中间任意一环选择“吃掉”而不重抛，整条链就断了。
快速验证方法：
- 在疑似问题切面的
catch块第一行加System.err.println("⚠️ 在切面X中捕获到: " + e.getClass().getSimpleName());，再手动触发一次必抛异常的请求（如传null参数） - 对比控制台输出：如果看到这行打印，但后续没进全局异常处理器、也没在监控平台看到对应错误指标，则基本确认是切面截断了传播
- 用IDEA设置“Java Exception Breakpoint”，类型选
RuntimeException，勾选“On caught exceptions”和“On uncaught exceptions”，运行时就能直接停在原始抛出处，跳过切面干扰
修复切面异常处理逻辑
不是不能捕获，而是捕获之后必须明确异常去向。监控“看得见”，前提是异常能浮到上层可采集的位置。
推荐写法（以记录+重抛为例）：
- 统一用
catch (Throwable t)覆盖所有可能，避免遗漏；若业务明确不处理Error，再单独过滤 - 记录必须含完整堆栈：
log.error("【切面拦截】{} 执行失败", joinpoint.getSignature(), t);（注意把t作为最后一个参数传入，slf4j才能解析为异常） - 必须重抛：
throw t;或包装后抛：throw new ServiceException("业务执行异常", t); - 若需返回兜底值（如降级），建议仅对特定异常类型做，且仍要记录+告警，例如：
if (e instanceof TimeoutException) { log.warn("调用超时，启用降级"); return fallbackResult; } else { throw e; }
补充监控与预防手段
靠人工 review 切面代码容易遗漏，需要机制化兜底。
- 在CI阶段加入静态检查规则：用SonarQube或自定义Checkstyle规则，扫描所有
@Around方法中是否存在catch块但无throw语句 - 给核心服务配置
Thread.setDefaultUncaughtExceptionHandler，即使异常逃逸出切面和Spring MVC，也能被最后防线捕获并上报 - 在全局异常处理器里增加校验：对未进入该处理器的
RuntimeException，反查调用栈是否含常见切面类名（如"LogAspect"、"MetricAspect"），发现高频绕过即预警 - 对关键接口开启全链路Trace，观察Span状态：若HTTP状态码是200但Span标记为
error，说明异常被内部消化了
