Java异常设计核心是按业务决策建模：checked异常用于需调用方处理的临时故障（如ServiceUnavailableException），unchecked用于代码错误（如InvalidOrderStateException）；用抽象基类收敛共性，类名体现动作（如PaymentTimeoutRetryableException），字段结构化而非拼接字符串。

Java 中设计清晰的异常层级结构，核心是让 catch 有明确语义、让调用方能区分「该重试」「该告警」「该静默吞掉」还是「必须向上抛」——不是堆砌类，而是按业务决策点建模。

按「是否该由调用方处理」切分 checked vs unchecked

Java 异常体系天然分两层：继承

• 如果下游服务暂时不可用（如 HTTP 调用超时）、资源临时不可得（如数据库连接池满），属于「调用方可能重试或降级」的场景，定义为 ServiceUnavailableException extends Exception
• 如果参数明显非法（如传入负数 ID 查询用户）、状态已破坏（如订单已关闭却尝试发货），属于「调用方代码有 bug 或逻辑错乱」，定义为 InvalidOrderStateException extends RuntimeException
• 绝不把网络超时包装成 RuntimeException；也别把空指针校验失败包装成 Exception——这会让调用方误以为需要显式处理

用抽象基类收敛共性，避免平行异常爆炸

一个微服务里动辄十几种业务异常，但很多共享错误码、日志上下文、重试策略。直接定义二十个独立类，维护和 catch 都会失控。正确做法是：

• 定义一个包级可见的抽象基类，如 BaseBusinessException extends RuntimeException，封装 errorCode、traceId、getLocalizedMsg() 等通用能力
• 具体异常只负责表达「是什么错」，例如 InsufficientBalanceException extends BaseBusinessException，构造时传入固定 "BALANCE_INSUFFICIENT" 错误码
• 避免出现 InsufficientBalanceException 和 BalanceNotEnoughException 这种语义重复的并行类

异常类名必须体现「决策动作」而非「错误现象」

异常最终要驱动程序分支逻辑，类名是第一线索。看到类名就该知道下一步怎么走：

• ✅ 好名字：PaymentTimeoutRetryableException（暗示可重试）、InvalidCouponNonRetryableException（暗示应终止流程）
• ❌ 坏名字：PaymentTimeoutException（没说清能否重试）、IllegalCouponException（无法判断是参数错还是状态错）
• 类名里可带 Retryable、NonRetryable、Validation、ExternalService 等前缀，但避免用 Error、Fail、Problem 这类无信息量的词

避免在异常中塞业务数据，改用 getter 暴露结构化字段

异常对象常被日志框架序列化、跨服务传递、甚至存入审计库。把原始数据拼进 getMessage() 会导致解析困难：

• ❌ 错误写法：new InsufficientBalanceException("user:1001, balance:2.5, required:10.0")
• ✅ 正确写法：在 InsufficientBalanceException 中定义 private final long userId;、private final BigDecimal currentBalance; 等字段，提供对应 getter；getMessage() 只返回可读提示，如 "Insufficient balance for user " + userId
• 这样下游可用 exception.getUserId() 直接取值做补偿，不用正则匹配字符串

最易被忽略的一点：异常类本身是 API 的一部分。一旦发布到生产，新增字段、修改继承关系、删掉 getter，都可能破坏下游的 catch 分支或日志解析逻辑——比接口变更更隐蔽，修复成本更高。