AOP替代分散try-catch是为了消除业务代码中异常处理逻辑的污染，将错误响应、日志、重试等非主干逻辑抽离，使方法专注核心业务；优先统一拦截可预期业务异常、框架通用异常和未检查异常，而需流程控制的异常仍应在业务层处理。
用AOP替代分散的try-catch不是为了炫技，而是解决业务代码被异常处理逻辑“污染”的实际问题。核心在于：把错误响应、日志、重试等非主干逻辑抽离出去，让Controller或Service方法只专注“做什么”，而不是“出错了怎么办”。
明确哪些异常该交给AOP统一拦截
不是所有异常都适合AOP处理。优先考虑以下三类：
-
可预期的业务异常：如参数校验失败（
IllegalArgumentException）、权限不足（AccessDeniedException）、资源不存在（自定义NotFoundException）——它们有明确语义，适合统一包装成前端友好的提示 -
框架/中间件抛出的通用异常：如
SQLException、HttpClientErrorException、RedisConnectionFailureException——这些通常不需业务层逐个捕获，由AOP转为系统级错误码和提示 - 未声明检查异常（RuntimeException及其子类）：比如空指针、数组越界、JSON解析失败——它们本就不该在业务方法里显式catch，而应由AOP兜底记录并返回500类响应
反之，像需要立即重试、补偿事务、或触发特定状态机流转的异常，仍应在业务代码中用try-catch精准控制流程。
用自定义注解绑定接口级错误提示
全局异常处理器（@RestControllerAdvice）只能按异常类型区分处理，但不同接口对同一异常的提示语往往不同。例如“用户不存在”在登录接口提示“账号未注册”，在订单接口则提示“收货人信息无效”。这时用AOP + 注解更灵活：
立即学习“Java免费学习笔记（深入）”；
- 定义注解：
@ExceptionResult("订单创建失败，请检查地址")，标注在Controller方法上 - AOP切面通过
@Around拦截该方法，捕获异常后读取注解值，覆盖默认错误消息 - 切点表达式示例：
@Around("@annotation(com.example.annotation.ExceptionResult)")
这样既避免了每个接口写重复的try-catch，又保留了提示语的业务上下文精度。
切面中做异常转化与分级处理
AOP切面不是简单地打印日志或返回固定JSON。它应承担“异常翻译官”的角色：
- 将底层技术异常（如
JpaSystemException）转化为带业务含义的自定义异常（DatabaseOperationException），再交由全局处理器统一格式化 - 对敏感异常（如SQL注入尝试产生的
SQLException）做脱敏处理，不向客户端暴露数据库细节 - 根据异常类型决定是否记录全量堆栈（仅开发/测试环境）或仅记录关键字段（生产环境）
- 对高频异常（如第三方服务超时）添加计数器，触发告警而非每次记录日志
注意AOP与全局异常处理器的协作顺序
很多人误以为AOP能完全取代@RestControllerAdvice。实际上二者是协作关系：
-
@RestControllerAdvice是第一道拦截，覆盖所有@Controller方法抛出的异常 - AOP切面（如
@AfterThrowing）在异常已被全局处理器捕获后仍会执行——这意味着它更适合做“事后审计”，比如记录异常发生时的用户ID、请求路径、耗时，而非修改响应内容 - 若需在AOP中修改响应（如替换错误消息），必须用
@Around环绕通知，并主动调用proceed()前/后控制流程，此时要小心避免与全局处理器冲突
实践中推荐：全局处理器负责响应体格式和HTTP状态码；AOP负责日志增强、监控埋点、跨服务链路追踪等横向动作。
