当 REST 接口抛出自定义业务异常（如支付处理器不一致）时，若未全局捕获并规范响应，Spring 默认将其转为 500 内部服务器错误；本文教你通过 @RestControllerAdvice 统一处理异常，返回指定 HTTP 状态码与结构化错误信息。
当 rest 接口抛出自定义业务异常（如支付处理器不一致）时，若未全局捕获并规范响应，spring 默认将其转为 500 内部服务器错误；本文教你通过 `@restcontrolleradvice` 统一处理异常，返回指定 http 状态码与结构化错误信息。
在实际开发中，类似“校验多个订单项是否使用同一支付渠道”的业务逻辑非常常见。例如，你从请求体中提取 items 列表，并检查所有元素的 paymentProcessor 字段是否一致：
List<string> paymentProcessors = items.stream()
.map(Item::getPaymentProcessor)
.collect(Collectors.toList());
if (paymentProcessors.isEmpty() ||
Collections.frequency(paymentProcessors, paymentProcessors.get(0)) != paymentProcessors.size()) {
throw new PaymentProcessorMismatchException("Multiple payment processors are not supported!");
}</string>
⚠️ 注意：直接 throw new ExceptionHandler(...) 并不能控制 HTTP 响应——ExceptionHandler 若仅为普通类（非 Spring 管理的异常处理器），其构造或抛出行为不会被框架识别，最终由 Spring 默认异常解析器兜底，返回 500 Internal Server Error 及空白/堆栈体响应，完全丢失你的业务提示信息。
✅ 正确做法是：定义受检/非受检业务异常 + 全局异常处理器。推荐使用运行时异常（避免强制 try-catch），例如：
public class PaymentProcessorMismatchException extends RuntimeException {
private final HttpStatus status = HttpStatus.BAD_REQUEST;
public PaymentProcessorMismatchException(String message) {
super(message);
}
public HttpStatus getStatus() {
return status;
}
}
然后创建全局异常处理组件：
@RestControllerAdvice
public class GlobalRestExceptionHandler {
@ExceptionHandler(PaymentProcessorMismatchException.class)
public ResponseEntity<errormessagedto> handlePaymentProcessorMismatch(
PaymentProcessorMismatchException ex) {
ErrorMessageDto error = new ErrorMessageDto();
error.setMessage(ex.getMessage());
error.setTimestamp(Instant.now());
return ResponseEntity.status(ex.getStatus()).body(error);
}
}
// 响应 DTO 示例
public class ErrorMessageDto {
private String message;
private Instant timestamp;
// getters & setters...
}</errormessagedto>
? 关键要点：
- @RestControllerAdvice 会拦截整个应用中所有 @RestController 抛出的异常；
- 异常处理器方法需用 @ExceptionHandler(YourException.class) 明确声明捕获类型；
- 返回 ResponseEntity
可精确控制状态码、响应头与响应体； - 建议为不同业务场景设计专属异常类（如 InsufficientBalanceException、InvalidCardTypeException），便于分类处理与监控。
这样，当两个 item 的 paymentProcessor 分别为 "MPGS" 和 "xx" 时，接口将返回清晰的 400 Bad Request 响应：
{
"message": "Multiple payment processors are not supported!",
"timestamp": "2024-06-15T10:30:45.123Z"
}
而非令人困惑的 500 错误页——既提升 API 可用性，也利于前端统一错误处理与用户提示。
