java异常处理架构的灵活性体现在分层设计与语义分离：检查型异常强制契约但可绕过，运行时异常支撑业务建模，框架统一治理（如@controlleradvice、网关降级），并融入可观测性（指标、熔断、上下文日志）。
Java异常处理架构的灵活性，不在于能否“捕获所有错误”，而在于它通过分层设计和语义分离，把不同性质的问题交给最适合的层级去应对。
检查型异常强制契约，但可被合理绕过
编译期强制处理 IOException、SQLException 等，本意是让开发者直面外部不确定性。这种约束在早期系统中提升了健壮性，但也容易导致“假处理”——比如 catch 后只打印日志却不恢复或反馈。现代实践中，常见解法包括：
- 用 try-with-resources 自动释放资源，减少手动 finally 的冗余
- 将 checked 异常包装为自定义 RuntimeException（如 DataAccessException），避免污染 service 层签名
- 在 Spring 等框架中，模板类（JdbcTemplate、RestTemplate）已默认完成转译，上层代码无需声明 throws
运行时异常支持业务语义建模
RuntimeException 不受编译器约束，反而成为表达业务规则的理想载体。例如：
- 定义 InsufficientBalanceException、OrderAlreadyShippedException 等领域异常，直接抛出即可中断流程
- 配合 @ControllerAdvice + @ExceptionHandler，统一转换为 HTTP 状态码与结构化 JSON 响应
- 在函数式风格中，用 Either
或 Result 封装代替抛异常，把错误变成返回值的一部分
全局与局部协同，避免异常处理碎片化
单一 try-catch 容易散落在各处，而架构级灵活性体现在统一治理能力：
- Spring Boot 的 @RestControllerAdvice 可按包、异常类型、HTTP 方法精细拦截
- 微服务中，网关层（如 Spring Cloud Gateway）可兜底处理下游服务返回的异常码，做降级或重试
- 结合 MDC（Mapped Diagnostic Context），在异常日志中自动注入 traceId、userId，提升排查效率
异常不是终点，而是可观测性的起点
真正体现架构弹性的，是异常如何融入整个系统生命周期：
- 抛出异常时自动触发指标上报（如 Prometheus counter），用于监控错误率突增
- 特定异常（如 TimeoutException）可触发熔断器状态切换（Hystrix / Resilience4j）
- 日志中记录堆栈的同时，补充上下文快照（如请求参数、数据库查询语句），而非仅靠 printStackTrace
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
