统一响应结构是前提，需定义result封装code、message、data、timestamp；@controlleradvice+@exceptionhandler实现全局异常分层处理，优先捕获业务异常，再处理框架异常，最后兜底throwable；日志脱敏并集成traceid与监控。
直接抓住三个关键点：统一响应结构、@ControllerAdvice + @ExceptionHandler 组合、业务异常与系统异常分层处理。面试官最想确认你是否真懂“为什么这么设计”，而不是只会贴代码。
统一响应体是前提，不是可选项
没有标准返回格式，全局异常就失去意义。必须定义一个通用结果类（如 Result<t></t>），至少包含 code（状态码）、message（语义化提示）、data（可选业务数据）、timestamp（便于排查）。状态码建议用枚举管理（如 ResultCode.NOT_FOUND），避免硬编码数字。
- 4xx 异常对应客户端错误，比如
400（参数校验失败）、401（未认证）、403（无权限）、404（资源不存在） - 5xx 异常对应服务端问题，比如
500（未知异常）、503（服务不可用）、504（网关超时） - 不要把数据库异常细节（如 SQL 错误、堆栈）直接暴露给前端，要兜底转换为用户友好的提示
@ControllerAdvice 是全局拦截的入口
它不是写在某个 Controller 里，而是独立的、被 Spring 扫描到的切面类。加了 @RestControllerAdvice 就自动具备返回 JSON 的能力，无需再加 @ResponseBody。
- 一个项目通常只配一个全局处理器，避免多个
@ControllerAdvice类互相覆盖或逻辑混乱 - 可通过
basePackages指定生效范围，比如只处理com.example.api下的控制器异常 - 如果同时存在多个
@ControllerAdvice，可通过@Order控制优先级，数值越小越先执行
分层捕获异常，拒绝“一个 Exception.class 兜到底”
粗暴地用 @ExceptionHandler(Exception.class) 捕所有异常是典型反例。正确做法是按粒度逐级处理：
- 优先捕获自定义业务异常（如
BusinessException、ResourceNotFoundException），直接返回对应 HTTP 状态码和友好 message - 再捕获 Spring 自带的异常（如
MethodArgumentNotValidException处理参数校验失败，HttpRequestMethodNotSupportedException处理不支持的请求方式） - 最后用
@ExceptionHandler(Throwable.class)或Exception.class做兜底，记录完整日志并返回 500，但 message 必须脱敏（例如：“系统繁忙，请稍后再试”） - 注意：不要忽略
NullPointerException、IllegalArgumentException这类运行时异常——它们往往暴露逻辑漏洞，应归入兜底或单独处理并告警
加分项：结合日志与可观测性
真正的高可用系统，异常处理不只是返回 JSON。可以简要提一句实践细节：
- 在每个
@ExceptionHandler方法里调用log.error("API异常", e)，确保堆栈进日志系统（如 ELK 或 Loki） - 对高频异常（如重复提交、频繁限流）加唯一 traceId，方便前后端联查
- 生产环境可对接 Sentry 或 Prometheus，让异常成为可观测指标的一部分
