java中利用aop记录受检异常需用@around在声明抛出该异常的方法出口拦截，提取traceid、method、exceptiontype等结构化字段，异步推送至中间件并原样重抛异常以保持语义。
Java中利用AOP切面将受检异常（checked exception）优雅记录到中间件日志，核心在于：不破坏原有业务逻辑、不强制上层处理异常、不丢失异常上下文，同时确保日志能被中间件（如ELK、SLS、Logback+Kafka等）可靠采集。
明确切点：只拦截真正需要记录的受检异常
受检异常本身必须显式声明或捕获，因此不能靠 throwing 通知捕获所有未处理异常。更合理的方式是：在业务方法抛出受检异常的**出口处**统一拦截——即在声明抛出该异常的方法执行完成后，发现异常被抛出时记录。
- 使用
@Around切面，在方法执行后判断返回值或捕获Throwable，但注意：受检异常若未被捕获，会直接向上抛出，@Around中可捕获并记录，再选择重新抛出 - 推荐切点表达式：
@annotation(org.springframework.web.bind.annotation.RequestMapping) || execution(* com.xxx.service..*.*(..) throws java.io.IOException, javax.validation.ValidationException)—— 显式限定抛出特定受检异常的 service 层方法 - 避免切
throws Exception这类宽泛声明，防止误拦运行时异常或干扰正常流程
封装异常日志结构：适配中间件字段规范
中间件日志（如ES索引、SLS topic）通常要求结构化字段。不要只记 e.toString()，应提取关键元数据：
- traceId：从 MDC 或 Sleuth/Baggage 中获取，保证链路可追溯
- method：目标方法全限定名 + 参数签名（可截取前100字符，防日志过长）
-
exceptionType：
e.getClass().getSimpleName() -
message：精简提示，如
e.getMessage()（避免敏感信息，如密码、token） - stackTrace：建议异步写入独立字段或单独日志流，主日志中仅存摘要（如前3行 + hash）
-
level：固定为
ERROR，但可在日志内容中标注“CHECKED_EXCEPTION”便于过滤
非阻塞记录：避免拖慢主流程
中间件日志（尤其走网络或磁盘）不应同步阻塞业务线程。正确做法是：
- 在切面中构造日志对象（POJO），提交至内存队列（如
Disruptor、BlockingQueue） - 由独立守护线程消费队列，序列化为 JSON，通过 Logback 的
KafkaAppender、HttpAppender或自研 SDK 异步推送 - 若使用 SLF4J + Logback，可配置
AsyncAppender包裹自定义的中间件 Appender，无需改动切面逻辑 - 务必设置队列容量上限与拒绝策略（如丢弃旧日志或降级为本地文件），防止 OOM
保持异常语义：记录 ≠ 吞掉
AOP 记录异常不是为了替代异常处理，而是增强可观测性。关键原则：
- 切面内 必须 re-throw 原始异常（或包装后抛出），否则上层无法按契约做恢复、重试或用户提示
- 禁止在切面中
catch后return null或静默吞掉异常——这会让调用方误以为成功 - 若需补充上下文（如当前用户ID、订单号），可用
new MyCheckedException(e).addContext("orderId", orderId)包装后再抛出，原始栈不丢失
不复杂但容易忽略：受检异常的日志价值，在于它代表了系统预期中的失败路径。AOP 不是兜底方案，而是让每一条“已知的失败”都留下可查、可溯、可聚合的痕迹。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
