全局异常处理需建立前后端统一的错误通信协议，涵盖HTTP状态码映射、分离的成功/失败响应结构、枚举化错误码、分层异常拦截顺序，确保语义清晰、安全可控、易于维护。
全局异常处理中规范全系统的异常响应契约，核心是建立一套前后端共同遵守的“错误通信协议”，不是只让后端返回整齐 JSON 就算完成，而是从 HTTP 状态码、响应体结构、错误码体系、语义边界到日志与安全控制，全部对齐。
明确 HTTP 状态码与业务语义的映射关系
状态码不是摆设，它承担着第一层语义判断责任：
- 4xx 类（客户端错误）：参数校验失败（400）、未登录（401）、权限不足（403）、资源不存在（404）——代表请求本身不合法或不可达，前端应引导用户修正操作
- 5xx 类（服务端错误）：数据库超时、连接池耗尽、NPE 等系统级异常（500）——代表服务暂时不可用，前端应提示“稍后再试”，不重试敏感操作
- 6xx 或自定义范围（如 4xx 扩展）：纯业务规则拒绝，如“库存不足”“手机号已注册”——属于合法业务流程分支，不是 bug，应返回 400 或 409，并带明确业务错误码
响应体结构必须严格分离成功与失败路径
不要用一个泛型类（如 ApiResponse<T>）强行包裹所有情况。正确做法是：
- 成功响应：
ResponseEntity<ApiResponse<T>>，HTTP 状态码为 200/201，体中含data、message、timestamp - 错误响应：
ResponseEntity<ErrorResponse>，HTTP 状态码为对应 4xx/5xx，体中含status（即 HTTP 状态码）、message（用户可见提示）、errors（可选，如字段校验详情）
前端只依赖response.status判断成败，再按类型解析对应 DTO，避免用data == null或code != 200这类脆弱逻辑
错误码必须枚举化、分层化、不可魔数化
所有错误码统一由枚举管理，例如：
public enum ResultCode {
SUCCESS(200, "操作成功"),
BAD_REQUEST(400, "请求参数错误"),
USER_NOT_FOUND(601, "用户不存在"),
STOCK_INSUFFICIENT(602, "库存不足"),
SYSTEM_ERROR(500, "系统繁忙，请稍后再试");
private final int code;
private final String msg;
}好处是：编译期校验、IDE 自动提示、模块间复用、文档可生成、避免 if (code == 601) 散布各处
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
异常分类拦截必须有明确优先级和职责边界
在 @RestControllerAdvice 中按如下顺序声明 @ExceptionHandler 方法：
- 先捕获
BusinessException（自定义业务异常），直接映射为ErrorResponse并返回对应状态码（如 601 → 404） - 再捕获 Spring 校验异常（如
MethodArgumentNotValidException），提取BindingResult字段级错误，组装为errors列表 - 最后兜底
Exception，记录完整堆栈日志，但响应体只返回通用提示（如 “系统繁忙”），绝不暴露技术细节
这样既保证业务异常可读可控，又防止系统异常信息泄露，还避免因顺序错乱导致异常被宽泛捕获而丢失上下文
不复杂但容易忽略
