业务异常是设计好的可预期失败，如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 里按类型分流处理
全局异常处理器不是“兜底大杂烩”，而是要严格区分流向：
立即学习“Java免费学习笔记（深入）”；
-
@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 框架层约定统一错误码协议，而不是靠异常类名判断类型。
