统一异常响应格式是微服务异常处理的前提，需定义标准JSON结构（code、message、requestId、timestamp），通过@ControllerAdvice集中处理三类异常，区分4xx/500/503等错误类型并协同网关与熔断器实现降级闭环。
统一异常响应格式是微服务异常处理的前提
微服务中各服务独立部署、语言和技术栈可能不同，但对外暴露的 API 必须有统一的错误结构。Java 服务应避免直接抛出原始异常（如 NullPointerException 或 SQLException），而是封装为标准 JSON 响应体，例如：
- code：业务错误码（如 40001 表示参数校验失败，50002 表示下游服务超时）
- message：面向调用方的简明提示（如“用户ID不能为空”）
- requestId：全链路唯一标识，用于日志追踪
- timestamp：错误发生时间
使用全局异常处理器拦截所有未捕获异常
Spring Boot 项目推荐使用 @ControllerAdvice + @ExceptionHandler 实现集中异常处理。重点拦截三类异常：
- 业务异常（自定义 BusinessException，直接转成 200 状态码 + 错误体）
- 系统异常（如 RuntimeException，返回 500 并记录堆栈到 ELK/Sentry）
- HTTP 异常（如 HttpMessageNotReadableException，统一转为 400 参数错误）
注意：不要在全局处理器里吞掉异常日志，至少记录 error 级别 + requestId。
区分异常类型，避免“一锅端”式处理
不是所有异常都该被“友好提示”。需按影响范围和可恢复性分类处置：
立即学习“Java免费学习笔记（深入）”；
- 客户端错误（4xx）：参数缺失、权限不足等，前端可感知并修正，返回明确 message 即可
- 服务端临时错误（503/504）：依赖服务不可用或超时，建议加 retry 机制，并返回带重试建议的提示（如“请稍后重试”）
- 严重内部错误（500）：如数据库连接池耗尽、线程死锁，不应暴露细节，仅记录完整堆栈供运维排查
与网关和熔断器协同做异常降级
单靠 Java 层处理不够，需结合微服务基础设施：
- API 网关（如 Spring Cloud Gateway）统一拦截 4xx/5xx 响应，补充 traceId、标准化 header（如 X-Error-Code）
- 熔断器（如 Resilience4j）配置 fallback 方法，在依赖服务失败时返回兜底数据或缓存结果，而非抛异常
- 调用方收到非 200 响应时，应解析 code 字段做分支处理，而不是只看 HTTP 状态码
基本上就这些。异常治理不是写几个 try-catch，而是从协议、日志、链路、降级多个层面形成闭环。
