17370845950

业务异常是设计好的可预期失败，如OrderNotFoundException；系统异常是需修复的程序缺陷，如空指针。二者须严格区分处理：业务异常继承RuntimeException并全局捕获返回400，系统异常记录告警返回500。

业务异常是“规则不满足”，系统异常是“程序崩了”

业务异常是你设计好的、可预期的失败场景，比如 OrderNotFoundException、InsufficientBalanceException；它不表示代码写错了，而是用户操作或数据状态触发了业务约束。系统异常则是程序本身出了问题：空指针、数组越界、数据库连接断开、JVM 内存溢出（OutOfMemoryError）——这些不是你“想让它发生”的，而是必须修复的缺陷。

关键区别在于：业务异常该被 捕获并友好反馈，系统异常该被 记录、告警、隔离甚至熔断。混淆二者会导致两种后果：把空指针当业务异常吞掉（掩盖 bug），或把余额不足当成系统错误重试三次（引发重复扣款）。

用继承关系明确分层：业务异常继承 RuntimeException

Spring 默认只对 RuntimeException 及其子类回滚事务，而业务异常本就不该让调用方强制 try-catch（否则 Controller 层会堆满冗余逻辑）。所以标准做法是：

• 自定义 BusinessException 继承 RuntimeException，带 code 和 message 字段
• 系统异常保留原始类型：如 SQLException、TimeoutException、NullPointerException
• 数据访问层（DAO）捕获 SQLException 后，不直接抛给上层，而是转为更语义化的业务异常或封装为系统异常（如 DataAccessException）

public class BusinessException extends RuntimeException {
    private final String code;
    public BusinessException(String code, String message) {
        super(message);
        this.code = code;
    }
    public String getCode() { return code; }
}

@ControllerAdvice 里按类型分流处理

全局异常处理器不是“兜底大杂烩”，而是要严格区分流向：

• @ExceptionHandler(BusinessException.class) → 记 WARN 日志，返回 400 Bad Request + 统一响应体（含 code 和提示文案）
• @ExceptionHandler(Exception.class) → 记 ERROR 日志（带完整堆栈），返回 500 Internal Server Error，且 绝不暴露数据库表名、SQL 或路径信息
• 特别注意：不要用 catch (Exception e) 包住整个 service 方法——这会让事务失效，且掩盖真实异常类型

分布式调用中，异常必须可序列化且带上下文

微服务之间传异常，不能靠 JVM 堆栈——跨进程后就丢了。Resilience4j、Feign、Dubbo 等框架都依赖异常的序列化能力：

• 自定义业务异常必须实现 Serializable
• 系统异常如 TimeoutException 虽可序列化，但建议在 RPC 客户端统一包装成 RemoteCallException(code="RPC_TIMEOUT", message="调用下游超时")
• 日志中务必补全 traceId、userId、method、params —— 没有上下文的 BusinessException("库存不足") 在线上等于没日志

最容易被忽略的是：本地抛出的 BusinessException 到了下游服务，可能变成 RuntimeException 被重新包装。这时需在网关或 RPC 框架层约定统一错误码协议，而不是靠异常类名判断类型。