优雅处理隐式运行时异常的核心是分层拦截、语义归类、精准响应，需按类型区分参数类（400）、状态类（409）、一致性类（500）异常，并结合@ControllerAdvice优先级控制、AOP补充非Web场景捕获，以及错误码+国际化提示。
全局异常处理中优雅处理 NullPointerException 以外的隐式运行时异常，核心不是“兜住所有异常”，而是分层拦截、语义归类、精准响应。NPE 只是表象，真正要治理的是 未声明、未预期、未设防 的运行时异常，比如 IllegalArgumentException、IllegalStateException、ClassCastException、ConcurrentModificationException、NumberFormatException 等——它们往往源于参数校验缺失、状态误用、类型强转粗暴、并发误操作或格式解析失控。
按业务语义分类捕获，避免 Exception.class 一锅端
统一用 @ExceptionHandler(Exception.class) 捕获所有异常看似省事，实则掩盖问题本质，导致错误日志模糊、前端提示笼统、监控难以切片。应优先按具体异常类型分组处理：
-
参数类异常（
IllegalArgumentException、NumberFormatException、DateTimeParseException）：统一映射为 400 Bad Request，返回结构化错误体，含字段名、错误原因、建议格式（如{"field": "age", "reason": "must be a positive integer"}） -
状态类异常（
IllegalStateException、UnsupportedOperationException）：多因业务流程错位（如对已关闭订单重复支付），返回 409 Conflict，附带当前资源状态快照（如"orderStatus": "CLOSED"） -
数据一致性异常（
EmptyStackException、NoSuchElementException）：反映逻辑断言失败，不宜直接暴露给前端，可转为 500 并记录完整上下文（调用链、入参、关键变量值），供排查逻辑漏洞
用 @ControllerAdvice + @Order 控制拦截优先级
多个 @ControllerAdvice 类共存时，异常匹配顺序影响结果。例如：你既想对 IllegalArgumentException 做参数校验兜底，又想对自定义 BusinessException 做统一包装，必须明确优先级：
- 给参数校验处理器加
@Order(Ordered.HIGHEST_PRECEDENCE)，确保它最先响应原始输入异常 - 给业务异常处理器设
@Order(Ordered.LOWEST_PRECEDENCE)，作为兜底通道 - 避免在同一个处理器里混写
@ExceptionHandler(IllegalArgumentException.class)和@ExceptionHandler(RuntimeException.class)—— 后者会覆盖前者
结合 AOP 补充非 Controller 场景的异常捕获
@ControllerAdvice 只覆盖 Spring MVC 请求链路，对以下场景无效：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 定时任务（
@Scheduled方法内抛出的异常） - 异步方法（
@Async） - Filter 或 Servlet 初始化阶段
- 线程池中
execute()提交的 Runnable
此时需用 @Aspect 切入这些执行点，在 afterThrowing 中统一记录、告警或补偿。例如：
@Around("@annotation(org.springframework.scheduling.annotation.Scheduled)")
public Object handleScheduledException(ProceedingJoinPoint joinPoint) throws Throwable {
try {
return joinPoint.proceed();
} catch (Exception e) {
log.error("Scheduled task failed: {}", joinPoint.getSignature(), e);
alertService.send("定时任务异常: " + e.getMessage());
throw e; // 不吞异常，避免静默失败
}
}
为每类异常配专属错误码与国际化提示
不区分异常类型就返回通用提示（如“系统繁忙”），会让用户困惑、测试难验证、客服难定位。推荐做法：
- 定义枚举
ErrorCode，每个值对应一个异常类型+业务场景，如PARAM_INVALID(400, "param.invalid")、ORDER_STATUS_CONFLICT(409, "order.status.conflict") - 在
@ExceptionHandler方法中根据异常实例推导出对应枚举，再通过MessageSource解析多语言提示（如中文：“订单状态冲突，当前不可操作”；英文：“Order status conflict, action not allowed”） - 前端依据
code字段做差异化交互（如高亮错误字段、跳转特定帮助页），而非仅靠 message 字符串判断
