应继承 RuntimeException 而非 Exception，因其为 unchecked 异常，避免强制捕获污染业务逻辑；继承 Exception 会导致编译期强制处理，违背统一异常拦截设计。
为什么要继承 RuntimeException 而不是 Exception
业务异常通常不需要强制捕获，否则会在大量 try-catch 或 throws 中污染业务逻辑。Java 中 RuntimeException 及其子类属于 unchecked 异常，调用方无需显式处理；而直接继承 Exception 会变成 checked 异常，违背“业务异常应由上层统一拦截并转化”的设计意图。
常见错误：写成 class BizException extends Exception，导致 Service 方法签名被迫加 throws BizException，Controller 层又得重复处理，失去分层意义。
- 除非你明确需要编译期强制约束（极少见），否则一律继承
RuntimeException - 如果异常需跨服务序列化（如 Dubbo/Feign），确保类实现
Serializable并定义serialVersionUID - 避免空参构造器之外不提供
String message构造器，否则日志里看不到原始提示
BizException 最简可用定义模板
一个能立刻投入使用的业务异常类，核心是携带错误码、消息、可选上下文数据。不必一上来就搞泛型或建造者模式，先保证清晰、易扩展。
public class BizException extends RuntimeException {
private final int code;
public BizException(int code, String message) {
super(message);
this.code = code;
}
public BizException(int code, String message, Throwable cause) {
super(message, cause);
this.code = code;
}
public int getCode() {
return code;
}
}
说明：
立即学习“Java免费学习笔记（深入）”；
-
code建议用整数而非字符串——便于前端 switch 判断、日志聚合统计、监控告警规则匹配 - 不推荐在异常类里塞
static final错误码常量（如USER_NOT_FOUND(1001, "用户不存在")），会导致异常类膨胀且难以按模块归类；应单独建BizErrorCode枚举 - 若需传递动态参数（如 “用户
余额不足”），建议用 SLF4J 风格的占位符，在抛出时格式化： throw new BizException(2001, String.format("用户 %s 余额不足", userId));
如何与 Spring Boot 全局异常处理器配合
Spring Boot 的 @ControllerAdvice + @ExceptionHandler 是标准解法，但关键在于返回结构是否统一、HTTP 状态码是否合理、敏感信息是否过滤。
典型错误：所有 BizException 都返回 HttpStatus.INTERNAL_SERVER_ERROR(500)，导致前端无法区分“参数错”和“系统挂了”。
- 业务异常应返回
HttpStatus.OK(200)或HttpStatus.BAD_REQUEST(400)，取决于接口契约（REST API 普遍用 400，JSON-RPC 风格常用 200 + code 字段） - 全局处理器中不要打印
e.printStackTrace()，用log.warn("BizException occurred", e)即可；堆栈只对技术异常（NullPointerException等）有意义 - 务必检查响应体是否包含
exception、path等敏感字段——这些是默认BasicErrorController返回的，生产环境必须屏蔽
哪些情况不该抛 BizException
异常不是万能占位符。滥用会导致语义模糊、链路追踪断裂、重试逻辑失效。
- 参数校验失败（如 ID 为空、手机号格式错）——应走 JSR-303
@Valid+BindingResult，而不是手动if (id == null) throw new BizException(...) - 第三方服务超时或网络异常——这是技术异常，应捕获
TimeoutException/IOException，包装为自定义ThirdPartyException（继承RuntimeException），并考虑重试或降级 - 数据库唯一键冲突——本质是并发写入竞争，抛
BizException会让前端以为“业务不允许”，实际应转为更友好的提示（如“该名称已被使用”），且需确认是否真要阻止提交
真正该用 BizException 的，只有那些**业务规则明确禁止、且不可绕过**的情形：库存扣减为负、状态机非法跃迁、权限校验失败等。
