Java异常设计核心是按业务决策建模：checked异常用于需调用方处理的临时故障（如ServiceUnavailableException），unchecked用于代码错误（如InvalidOrderStateException）；用抽象基类收敛共性，类名体现动作（如PaymentTimeoutRetryableException），字段结构化而非拼接字符串。
Java 中设计清晰的异常层级结构，核心是让 catch 有明确语义、让调用方能区分「该重试」「该告警」「该静默吞掉」还是「必须向上抛」——不是堆砌类，而是按业务决策点建模。
按「是否该由调用方处理」切分 checked vs unchecked
Java 异常体系天然分两层：继承 Exception 的 checked 异常强制声明，继承 RuntimeException 的 unchecked 异常不强制。这个分界线必须对齐业务契约：
- 如果下游服务暂时不可用（如 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这种语义重复的并行类
异常类名必须体现「决策动作」而非「错误现象」
异常最终要驱动程序分支逻辑，类名是第一线索。看到类名就该知道下一步怎么走：
立即学习“Java免费学习笔记（深入）”；
- ✅ 好名字：
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 分支或日志解析逻辑——比接口变更更隐蔽，修复成本更高。
