全局异常响应需精简路径、控制范围、提前兜底，核心是固定轻量响应结构（code/message/timestamp）、禁止异常处理器调用业务逻辑、前置收敛异常分类、异步可控记录日志、在链路起点嵌入降级熔断。
要让全局异常响应既高效又稳定，关键不在“加功能”，而在于精简路径、控制范围、提前兜底。核心是减少异常处理过程中的不确定环节，避免在错误发生时再做复杂决策。
响应结构必须固定且轻量
所有异常返回必须走同一套序列化逻辑，不能因异常类型不同而切换 JSON 库、拼接方式或字段层级。推荐直接返回一个极简的 POJO（如 Result>），只含 code、message、timestamp 三个字段，不嵌套 data 或 extra。避免在异常处理器里调用 service、查数据库、读配置——这些操作本身可能再次抛异常，形成二次崩溃。
异常分类要前置收敛，不依赖运行时判断
业务异常（如参数非法、权限不足）和系统异常（如空指针、SQL 异常）必须在抛出前就明确区分，而不是在全局处理器里用 instanceof 或字符串匹配去“猜”。做法是：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 定义明确的自定义异常基类（如 BaseException），所有业务异常都继承它
- 系统异常统一由框架或中间件自动包装（如 MyBatis 抛出的 SQLException 可被拦截转为统一系统异常）
- 禁止在 Controller 层 catch 后再 throw 新异常——这会丢失原始堆栈，也破坏分类一致性
日志记录需异步且可控
异常发生时，同步写日志会拖慢响应，尤其在高并发下可能成为瓶颈。应做到：
- 使用 Logback 的 AsyncAppender 或 Log4j2 的异步模式，确保日志不阻塞主线程
- ERROR 级别日志只记录关键信息：异常类型、错误码、简明消息、请求 ID（traceId），不打印完整堆栈（除非 debug 开关打开）
- 对高频异常（如重复提交、限流拒绝）做采样记录，避免日志刷屏
降级与熔断要嵌入异常链路起点
真正影响稳定性的不是异常本身，而是异常引发的连锁反应。比如一个下游服务超时，若不及时熔断，会导致线程池耗尽、雪崩。因此：
- 在网关层（如 Spring Cloud Gateway）就配置统一超时和 fallback 响应，不让异常穿透到业务微服务
- 对非核心依赖（如统计上报、通知发送）采用“尽力而为”策略：异常时仅打日志，不中断主流程
- 全局异常处理器内不重试、不补偿、不调远程接口——它只负责“告知”，不负责“修复”
