Java自定义异常与业务状态码绑定的核心是通过继承统一基类（含code/message字段）并由子类固化状态码，再于@ControllerAdvice中统一转换为标准响应；推荐子类构造器绑定而非注解反射。
Java 中自定义异常与业务状态码的绑定映射，核心在于让异常携带可识别的业务语义，并在统一异常处理层（如 Spring 的 @ControllerAdvice）中将其转换为对应的 HTTP 状态码和响应体。关键不是“硬编码耦合”，而是建立清晰、可维护的映射关系。
定义带状态码的自定义异常基类
所有业务异常应继承一个统一基类，该基类持有 code（业务状态码，如 1001）、message（提示信息）等字段。避免每个异常类重复定义这些属性。
- 使用构造函数强制传入 code 和 message，保证实例化时必填
- 提供无参构造和默认 message 的重载，便于测试或快速抛出
- 不建议直接继承
RuntimeException后再手动塞字段——要封装成有语义的对象
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;
}
}
按业务场景派生具体异常子类
子类不负责存储状态码，而是通过构造器固定传递预设值，实现“异常类型 → 状态码”的静态绑定。这样调用方只需关心“抛什么异常”，无需记忆数字。
- 每个子类对应一个明确的业务失败场景（如用户不存在、库存不足、参数非法）
- 状态码在子类内部写死，例如
UserNotFoundException固定用2001 - 子类可额外提供业务字段（如缺失的 userId），用于丰富错误响应体
public class UserNotFoundException extends BusinessException {
private final Long userId;
public UserNotFoundException(Long userId) {
super(2001, "用户不存在：" + userId);
this.userId = userId;
}
}
在全局异常处理器中完成映射与响应
使用 @ControllerAdvice 拦截自定义异常，提取其 code 和 message，组装标准 JSON 响应（如 {"code":2001,"msg":"用户不存在：1001"}）。HTTP 状态码通常统一用 200（业务成功但结果失败），也可按需映射为 400、404 等语义化状态码。
立即学习“Java免费学习笔记（深入）”；
- 推荐统一返回
200+ 业务 code，前端统一解析code字段做跳转或提示 - 若需 HTTP 层语义（如 404），可在处理器中调用
response.setStatus(404) - 避免在 controller 内 try-catch 处理业务异常——破坏分层，且易遗漏
@ControllerAdvice
public class GlobalExceptionHandler {
@ResponseBody
@ExceptionHandler(BusinessException.class)
public Result handleBusinessException(BusinessException e, HttpServletResponse response) {
response.setStatus(200); // 或根据 e.getCode() 动态设 400/404/500
return Result.fail(e.getCode(), e.getMessage());
}
}
进阶：用注解 + 反射实现更松散的绑定
如果希望彻底解耦异常类与状态码（比如状态码由配置中心管理），可定义 @ErrorCode(2001) 注解，加在异常类上，处理器通过反射读取。但多数项目没必要过度设计——子类固化状态码已足够清晰、安全、易查。
- 注解方案适合多语言共用一套状态码体系、或状态码频繁变更的场景
- 注意反射性能开销极小，但增加理解成本；普通项目优先选子类构造器绑定
- 无论哪种方式，状态码定义建议集中在一个枚举类或常量类中，方便查阅和校验
