受检异常需显式处理，策略模式解耦多环境响应，责任链模式分层过滤异常类型，自定义异常承载业务语义，模板方法统一处理流程。
受检异常（Checked Exception）必须显式处理，否则编译不通过。但硬编码的 try-catch 容易导致业务逻辑被异常处理淹没，重复判断、嵌套过深、策略固化。设计模式不是为了炫技，而是把“怎么处理异常”这件事从代码里抽出来，让业务更干净、策略更可配、扩展更简单。
用策略模式解耦处理方式
不同场景对同一异常的响应可能完全不同：开发环境要打印堆栈便于调试，测试环境记录日志，生产环境则返回友好提示并上报监控。策略模式正好应对这种多变需求。
- 定义统一接口，如 ExceptionHandlerStrategy，声明
handle(Exception e)方法 - 为每种行为写具体实现类：LogStrategy、AlertStrategy、UserFriendlyStrategy、FallbackStrategy
- 在服务入口或 Controller 层注入策略上下文（ExceptionHandlerContext），运行时按配置或条件切换策略
- 避免在每个 service 方法里写 if-else 判断环境再决定怎么 catch —— 那是策略模式没用到位的表现
用责任链模式分层过滤异常
一个请求可能触发多种受检异常：文件读取失败（IOException）、数据库连接超时（SQLException）、配置解析错误（ParseException）。责任链能让它们各司其职，不互相干扰。
- 每个处理器只关心自己负责的异常类型，比如 IoExceptionHandler 只处理 IOException 及其子类
- 链式串联：Io → Sql → Config → Default，前一个不匹配就交给下一个，避免冗长的 instanceof 判断
- 支持动态插拔——上线新模块时，只需新增处理器并加入链尾，无需修改已有逻辑
- 特别适合 Spring 环境：可结合 @Order 或 Ordered 接口控制执行顺序
用自定义受检异常承载业务语义
直接 throw new IOException("用户头像上传失败") 是模糊的。受检异常的价值在于强制调用方思考“这个错我该怎么兜底”，前提是异常本身说得清问题本质。
- 继承 Exception（非 RuntimeException），确保编译器强制捕获
- 命名体现业务：如 InsufficientBalanceException、InvalidVerificationCodeException
- 提供带 errorCode 和 cause 的构造方法，方便上层统一包装成 API 响应体
- 配合全局异常处理器（@RestControllerAdvice），把所有自定义异常转为标准 JSON 格式，状态码与业务含义对齐
用模板方法统一处理流程
很多受检异常的处理步骤高度相似：记录日志 → 补偿操作（如回滚/重试）→ 返回结果。模板方法能把共性固化，把差异点留给子类实现。
- 抽象基类定义 executeWithExceptionHandling() 模板方法，内含 try-catch 框架和固定钩子（如 beforeHandle、afterHandle）
- 子类只需实现 doBusiness() 和 handleSpecificException()，不用重复写日志、事务回滚等样板代码
- 适用于批量操作、事务边界明确的场景，比如订单创建、支付回调等核心链路
- 比裸写 try-catch 更易维护，也比 AOP 切面更直观可控
