应使用自定义异常拦截业务状态不满足情形，核心是提前校验、主动抛出、精准捕获；需梳理非法可预判状态，定义带错误码的非检查型异常类，入口处集中校验并抛出，再通过@ControllerAdvice全局统一处理返回结构化结果。
在业务状态不满足时用自定义异常拦截，核心是“提前发现 + 主动抛出 + 精准捕获”，不是等错误发生后再兜底，而是把校验逻辑前置，让异常成为业务规则的执行开关。
明确哪些状态需要拦截
先梳理清楚业务中哪些状态属于“非法但可预判”的情形，比如：
- 用户已注销，却尝试提交订单
- 订单当前状态是“已发货”，却调用“取消订单”接口
- 账户余额不足，却发起扣款操作
- 活动未开始或已结束，却允许参与抽奖
这些都不是系统故障，而是业务流程中的约束条件。它们适合用自定义异常来表达——既语义清晰，又便于统一拦截和响应。
定义带业务语义的异常类
继承 RuntimeException（非检查型），避免强制 throws 干扰正常方法签名。同时建议加入错误码字段，方便前端或日志识别：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
public class BusinessException extends RuntimeException {
private final int code;
public BusinessException(int code, String message) {
super(message);
this.code = code;
}
public int getCode() {
return code;
}
}
再按场景细化子类，例如：
public class OrderStatusInvalidException extends BusinessException {
public OrderStatusInvalidException(String message) {
super(4001, "订单状态不合法: " + message);
}
}
在关键节点主动校验并抛出
不要把校验逻辑散落在 service 方法里，推荐在入口处（如 Service 方法开头）集中判断。示例：
public void cancelOrder(Long orderId) {
Order order = orderMapper.selectById(orderId);
if (!"待支付".equals(order.getStatus())) {
throw new OrderStatusInvalidException(
"当前状态为 " + order.getStatus() + "，仅支持取消待支付订单");
}
// 后续取消逻辑...
}
这样一旦状态不满足，立刻中断执行，不会继续走后续可能引发数据不一致的操作。
全局统一拦截并返回友好结果
用 @ControllerAdvice 捕获自定义异常，转成标准响应格式：
@ExceptionHandler(BusinessException.class)
@ResponseBody
public Result<?> handleBusinessException(BusinessException e) {
return Result.fail(e.getCode(), e.getMessage());
}
前端收到的是结构化错误码和提示，后端日志里也能按 code 快速归类问题，不需要翻堆栈找原因。
