Java自定义异常是业务校验逻辑的结构化表达，需分层封装、携带上下文信息，并结合AOP实现声明式校验，以提升语义清晰度、统一错误处理和增强可维护性。
Java 中自定义异常不是“加个类就完事”，而是业务校验逻辑的结构化表达。它能把散落在 if-else 里的判断条件，升级为可识别、可捕获、可统一处理的语义单元。关键不在抛出异常本身，而在如何让异常成为校验流程的自然出口。
用异常替代硬编码返回值，提升语义清晰度
避免在 service 层写类似 if (user == null) return Result.fail("用户不存在") 这类弱类型校验分支。改成：
- 定义
UserNotFoundException extends BusinessException，带固定错误码USER_NOT_FOUND_404 - 在查询后直接
if (user == null) throw new UserNotFoundException(); - 由全局异常处理器统一转成标准 JSON 响应（含 code/msg/data）
这样校验逻辑不再混杂业务主干，且所有“用户不存在”场景都走同一处理路径，前端也只需监听一个错误码。
分层封装校验异常，匹配不同粒度的业务场景
不要只建一个 BusinessException 包打天下。按领域建继承树，例如：
立即学习“Java免费学习笔记（深入）”；
-
OrderException下再细分OrderStatusInvalidException、OrderAmountMismatchException -
PaymentException下包含InsufficientBalanceException、PaymentTimeoutException
每种子异常携带专属错误码和用户提示文案，比如 ORDER_STATUS_INVALID_501 对应“当前订单状态不支持该操作”，比泛泛的“操作失败”更利于问题定位和用户理解。
构造时注入上下文，避免日志和调试信息丢失
自定义异常类中建议内置字段：errorCode、errorMessage（面向用户）、debugMessage（含参数快照、ID 等，仅记日志不返给前端）。例如：
- 抛出时：
throw new OrderAmountMismatchException("订单金额与支付单不一致", orderId, expectedAmount, actualAmount); - 构造方法内自动拼接
debugMessage = String.format("orderId=%s, expected=%.2f, actual=%.2f", ...)
这样排查时不用翻日志找关联请求，异常对象本身已携带关键现场信息。
配合注解或 AOP，把通用校验从代码中抽离
对重复性高的校验（如 ID 是否为空、金额是否大于 0），可结合 Spring Validation 或自定义注解 + AOP 实现声明式校验：
- 定义
@ValidOrderAmount注解 - AOP 切入 controller 方法参数，在运行时检查并抛出
OrderAmountInvalidException
业务方法体里就彻底干净了，校验逻辑集中维护，新增规则只需改注解或切面，不侵入业务代码。
