@RestControllerAdvice 配合分层 @ExceptionHandler 可实现有层次、有区分、有日志、不泄密的全局异常处理；需定义继承 RuntimeException 的自定义业务异常，统一命名并携带 error code 和用户提示；处理器按具体到宽泛排序，匹配 MethodArgumentNotValidException、BusinessException 子类、HTTP 异常，最后兜底 Exception；响应结构与 HTTP 状态码严格对齐，成功用 ResponseEntity<ApiResponse<T>>，错误用 ResponseEntity<ErrorResponse>；日志记录需含 URI、请求 ID、脱敏参数，生产环境禁用详细错误响应，敏感信息绝不外泄。
直接用 @RestControllerAdvice 配合分层的 @ExceptionHandler 方法，就能实现干净、可维护的全局异常处理。关键不是“全兜底”，而是“有层次、有区分、有日志、不泄密”。
定义清晰的自定义业务异常
所有业务规则失败（如“用户不存在”“库存不足”“权限拒绝”）都应抛出自定义异常，而不是用 RuntimeException 或系统异常硬凑。
- 继承 RuntimeException，避免强制 try-catch 干扰业务流
- 携带 error code（如 400101）、用户提示 message、可选的扩展字段（如错误参数名）
- 统一命名规范，比如 BusinessException、ValidationException、AuthException
编写分优先级的全局处理器
一个 @RestControllerAdvice 类里按异常类型从具体到宽泛排列处理方法，Spring 会自动匹配最精确的那个。
- 先处理
MethodArgumentNotValidException：捕获 @Valid 校验失败，提取字段错误并返回 400 - 再处理
BusinessException及其子类：返回对应 code + 用户友好提示，HTTP 状态码用 4xx（如 400/403/404） - 接着处理
HttpClientErrorException、HttpServerErrorException：封装第三方调用异常 - 最后用
@ExceptionHandler(Exception.class)兜底：生产环境只返回泛化提示（如“系统繁忙”），状态码设为 500，同时记录完整堆栈和请求上下文（URI、method、参数）
响应结构与 HTTP 状态码严格对齐
不要把成功和错误塞进同一个 Result
- 成功响应：Controller 返回
ResponseEntity<ApiResponse<T>>，状态码为 200/201/204 - 错误响应：GlobalExceptionHandler 返回
ResponseEntity<ErrorResponse>，状态码与语义匹配（400 参数错、401 未认证、403 拒绝、404 找不到、500 服务异常） - ErrorResponse 至少含 status（int）、message（用户可见）、timestamp，可选 errors（校验详情）或 traceId（用于日志追踪）
日志与安全必须同步落地
异常处理的价值一半在响应，另一半在可观测性。
- 每个 @ExceptionHandler 方法里用 log.error() 记录异常，带上 request URI、X-Request-ID（如有）、关键参数摘要（脱敏后）
- 敏感信息绝对不出现在响应体中：不返回 stacktrace、数据库地址、密码字段、内部类名
- 开发环境可开启详细错误（便于调试），生产环境禁用，通过日志+监控平台（如 ELK、Grafana）定位问题
- 对高频低风险异常（如 Token 过期、刷新令牌无效）可做日志降噪，避免刷屏
