该用@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 表示具体子错误。
立即学习“Java免费学习笔记（深入）”；
- 不要继承
RuntimeException后就不管父类构造函数，务必显式调用super(message, cause)保留原始堆栈 - 避免在自定义异常中重写
toString()或printStackTrace()，干扰日志框架行为 - 字段全部设为
final，防止被序列化/反序列化篡改
ResponseEntity 还是直接 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)</user> - 若强行用
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 并记录原始异常。
