Java业务异常应继承RuntimeException，因其代表可预期的业务失败，无需强制捕获；需按领域命名并隔离异常类，提供可读错误码字符串，于领域逻辑内层抛出，避免滥用catch控制流程。
业务异常该继承 RuntimeException 还是 Exception
Java 业务异常通常应继承 RuntimeException，而非 Exception。这不是风格偏好，而是语义约束：业务异常代表「流程中可预期的、非系统故障的失败」，比如余额不足、订单已取消、参数校验不通过——它们不该强制调用方用 try-catch 或声明 throws，否则会污染业务主干逻辑，让正常路径被异常处理淹没。
若继承 Exception，编译器强制上层处理，结果往往是泛化捕获：catch (Exception e) { log.error("", e); }，丢失业务语义；或草率抛出 throws Exception，把责任甩给更上层，破坏分层契约。
例外情况极少：仅当某类业务规则必须被所有调用链显式决策（如金融风控中的“需人工复核”状态），才考虑受检异常，但此时更推荐返回 Result 或状态枚举，而非异常。
如何命名和组织业务异常类
命名要直指业务动因，避免泛化词如 BusinessException 或 ServiceException。每个异常类对应一个明确的业务失败场景：
立即学习“Java免费学习笔记（深入）”；
-
InsufficientBalanceException（不是AccountException） -
OrderAlreadyShippedException（不是OrderException） InvalidPromotionCodeException
组织上建议按领域包隔离，例如：
com.example.order.exception.OrderAlreadyPaidException com.example.payment.exception.PaymentTimeoutException
不建议统一放在 exception 包下堆砌几十个类——难以定位，也削弱了领域边界感。同时，避免为省事复用同一个异常类传不同 message，这会让下游无法做精准类型判断（如重试策略、告警过滤）。
构造函数与错误码设计是否必要
必须提供带错误码的构造函数，且错误码不应是纯数字（如 1001），而应是可读字符串常量，例如：
