业务校验异常应使用自定义业务异常基类而非泛化exception；该基类继承runtimeexception，含errorcode和message字段，不重写fillinstacktrace，并按模块定义错误码枚举，service层主动抛出。
业务校验异常不该用 RuntimeException 或泛化 Exception 直接抛，而应走“可识别、可分类、可响应”的规范路径——核心是把“用户操作不合规”和“系统出错了”彻底分开。
定义统一的业务异常基类
继承 RuntimeException（非受检），避免强制上层 try-catch 干扰正常流程，同时携带错误码和提示信息：
- 字段至少包含
errorCode（字符串或枚举）和message - 构造方法支持传入错误码 + 自定义消息，也支持仅传错误码（消息由枚举内置）
- 不重写
fillInStackTrace()，保持堆栈简洁（业务异常不需要完整调用链）
按场景划分具体错误码枚举
把校验失败类型沉淀为枚举，比如登录、支付、库存等模块各自独立的错误码集：
- 例如
AuthErrorCode.PASSWORD_MISMATCH、PayErrorCode.INSUFFICIENT_BALANCE - 每个枚举项明确
code（如 "AUTH_002"）和defaultMessage（如 "密码错误"） - 前端可直接根据
errorCode做国际化或定制提示，无需解析 message 字符串
在 Service 层主动抛出，不穿透到 Controller
校验逻辑集中在 Service，发现不满足业务规则时立即抛出业务异常：
- 示例：
if (user.getBalance().compareTo(amount) - Controller 层不写 if 判断 + 手动 return 错误响应，避免错误处理逻辑分散
- 让全局异常处理器（
@ControllerAdvice）统一捕获BusinessException，组装成标准CommonResult.error(code, message)返回
日志与监控要区分对待
业务异常不是故障，但需要可观测：
- 全局处理器中用
logger.warn()记录，而非error()，避免污染 ERROR 日志看板 - 可额外打点：上报错误码、请求 ID、关键参数（脱敏后），用于统计高频失败场景
- 监控告警不触发业务异常（如“密码输错”不应发告警），只对系统异常（DB 连接超时、NPE 等）设 alert
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
