Java统一异常处理封装方法解析

该用@ControllerAdvice，但仅适用于Spring MVC/WebFlux的控制器层异常；需配合@ExceptionHandler显式声明异常类型，设计自定义异常时应包含code、timestamp、traceId字段，推荐返回Result而非ResponseEntity，全局处理器须记录带堆栈的error日志并防范自身抛异常。

统一异常处理该不该用@ControllerAdvice

该用，但只适用于 Spring MVC 或 Spring WebFlux 的 Web 层。它不是万能兜底，@ControllerAdvice 只捕获控制器方法抛出的异常，对过滤器（Filter）、拦截器（Interceptor）、异步线程（@Async）、定时任务（@Scheduled）或全局线程池里的异常完全无效。

常见误用是把所有 try-catch 都删掉，指望 @ControllerAdvice 拦住一切——结果 NullPointerException 在 Filter 里直接 500，日志都没进统一处理器。

• 只对 @RequestMapping、@GetMapping 等注解标记的 handler 方法生效
• 需配合 @ExceptionHandler 显式声明要捕获的异常类型，未声明的仍会向上冒泡
• 若多个 @ControllerAdvice 存在，按 @Order 或类名排序，顺序错可能导致覆盖

自定义异常类该怎么设计字段

别只塞一个 message。生产环境需要快速定位问题，至少保留三个核心字段：code（业务码）、timestamp（毫秒时间戳）、traceId（链路 ID）。其中 traceId 必须从 MDC 或请求上下文透传，不能在异常构造时硬编码生成。

code 推荐用整数而非字符串——便于前端 switch 判断，也避免拼写不一致（比如 "USER_NOT_FOUND" 和 "user_not_found"）。错误码建议分段设计，例如 100101：前两位 10 表示用户模块，中间两位 01 表示查询类错误，末两位 01 表示具体子错误。

• 不要继承 RuntimeException 后就不管父类构造函数，务必显式调用 super(message, cause) 保留原始堆栈
• 避免在自定义异常中重写 toString() 或 printStackTrace()，干扰日志框架行为
• 字段全部设为 final，防止被序列化/反序列化篡改

ResponseEntity<Result> 还是直接 return Result

直接 return Result 更干净。Spring Boot 默认配置下，只要控制器方法返回值不是 ResponseEntity，就会被 @ResponseBody 处理器自动包装成 JSON 响应体，状态码默认 200。

用 ResponseEntity 的唯一合理场景是：你需要动态控制 HTTP 状态码（比如成功时返回 201，或某些业务异常要返回 409），且这个状态码无法通过全局异常处理器统一映射。否则，硬塞 ResponseEntity.ok().body(new Result(...)) 只会让代码变啰嗦，还容易漏掉 headers 或 status 设置。

• 统一异常处理器中用 ResponseEntity.status(code).body(result) 控制状态码即可
• 控制器方法签名保持简洁，如 public Result<User> getUser(@PathVariable Long id)
• 若强行用 ResponseEntity，记得所有分支都显式指定 status，否则 null body 会触发 200 OK + 空响应体，前端难排查

全局异常处理器里要不要记录 error 日志

要，但必须记录原始异常（throwable），而不是只打 result.getMessage()。很多团队只记了 “用户不存在”，却没记是哪行代码、哪个参数、什么 SQL 导致的，查问题时只能靠猜。

更关键的是：日志级别必须用 error，且必须包含完整堆栈（logger.error("biz error", e)），不能只写 logger.error(e.getMessage())——后者会丢掉堆栈和 cause 链。

• 敏感信息如密码、身份证号、token 要在日志输出前脱敏，可借助 Logback 的 PatternLayout + 自定义 Converter
• 避免在异常处理器里做耗时操作（如发邮件、调远程接口），可能拖慢整个请求响应
• 如果用了 Sentry 或 SkyWalking，确保 throwable 被正确传递，否则告警里看不到堆栈

最常被忽略的一点：全局异常处理器本身也可能抛异常。比如 JSON 序列化失败、NPE 在构建 Result 时发生——这时 Spring 会 fallback 到默认错误页，你的统一逻辑彻底失效。务必在处理器内加最外层 try-catch 并记录原始异常。