应构建分层业务异常体系：业务异常（如余额不足）用BizException子类抛出，不打堆栈；系统异常（如NPE）需记录完整堆栈并修复；技术异常（如DB超时）统一兜底降级。
Java业务异常不该直接 throw new RuntimeException("xxx")，更不能让底层技术异常（如 SQLException、RedisConnectionException）穿透到上层业务逻辑。一套清晰、分层、可捕获、易监控的业务异常体系，是保障系统健壮性与可维护性的基础。
明确区分三类异常：业务异常、系统异常、技术异常
这是设计起点。混淆会导致处理逻辑混乱、日志泛滥、告警失真。
- 业务异常：代表业务规则被违反，属预期内失败，比如“余额不足”、“订单已取消”、“手机号已注册”。这类异常不打印堆栈，应被业务层主动捕获并转化为用户友好的提示。
- 系统异常：指应用自身逻辑缺陷导致的非预期错误，如空指针、数组越界、NPE。这类异常必须记录完整堆栈，属于 bug，需修复。
- 技术异常：来自外部依赖的故障，如数据库超时、HTTP 调用失败、MQ 发送异常。这类异常要统一兜底降级/重试，并标记为“外部依赖失败”，避免和业务逻辑混为一谈。
定义统一的业务异常基类与分层子类
避免满屏 new RuntimeException。建议定义一个抽象基类，再按模块或场景派生具体异常。
- 基类 BizException 继承 RuntimeException，含 errorCode（String）、message、args（用于参数化提示），默认不打印堆栈（重写 fillInStackTrace() 返回 this）。
- 子类示例：OrderBizException（订单域）、UserBizException（用户域）、PayBizException（支付域）。每个子类对应一组预定义 error code，如 ORDER_NOT_FOUND("ORDER_001")、INSUFFICIENT_BALANCE("PAY_002")。
- code 建议采用“模块_编号”格式，便于日志检索、监控聚合、前端国际化映射。
全局异常处理器统一拦截与响应
用 @ControllerAdvice + @ExceptionHandler 拦截所有未被捕获的异常，按类型差异化处理：
立即学习“Java免费学习笔记（深入）”；
- 捕获 BizException：返回 HTTP 200 + { "code": "PAY_002", "msg": "余额不足", "data": null }；记录轻量日志（如 traceId + code + userId + orderId）。
- 捕获 RuntimeException（非 BizException）：返回 HTTP 500 + 通用错误码；记录 ERROR 级别日志 + 完整堆栈；触发告警（如企业微信/钉钉机器人）。
- 捕获 IOException / TimeoutException 等技术异常：返回 HTTP 503 或自定义“服务暂不可用”码；记录 WARN 日志 + 依赖名 + 耗时；可集成熔断器（如 Sentinel）自动降级。
业务代码中只抛出语义明确的业务异常
杜绝在 service 层写 try-catch-log-rethrow，也避免把技术异常包装成业务异常（比如把 DB 连接失败说成“用户不存在”）。
- 校验失败时直接 throw new OrderBizException(ORDER_STOCK_SHORTAGE, "库存不足，剩余{0}件", stock)；前端根据 code 渲染对应提示。
- 调用下游接口前先做前置校验（如参数合法性、状态一致性），校验失败走 BizException；调用失败则原样抛出或转为技术异常封装，交由全局处理器兜底。
- 事务方法内慎用 try-catch 吞掉 BizException，否则 @Transactional 可能不回滚（需确保异常未被吞且是 RuntimeException 子类）。
基本上就这些。核心是让每种异常各司其职：业务异常讲人话、系统异常追根源、技术异常管依赖。体系建好了，排查省一半力，上线少一半火。
