受检异常本质是编译期契约，适用于外部资源强依赖且需调用方决策的场景；在业务分层与函数式编程中易破坏封装、阻碍抽象；现代实践通过异常翻译、语义化运行时异常、统一响应体和工具方法实现更合理的错误处理。
受检异常不是“该不该用”的二选一问题，而是“在哪用、怎么用”的上下文判断问题。它本质是一种编译期契约：告诉调用方“这事可能因外部环境失败，你得想好怎么办”。用对地方能提升可靠性；用错位置，反而污染逻辑、掩盖真实意图。
它真正有用的地方：外部资源强依赖场景
当操作成败完全取决于不可控的外部因素，且失败后无法自动恢复、必须由调用方决策时，Checked Exception才体现价值。
- 文件系统操作（如 FileInputStream 构造时抛 FileNotFoundException）——调用方需决定是提示用户、换路径还是终止流程
- 类加载（ClassNotFoundException）——反射调用前必须确认类存在，否则业务无法继续
- 线程中断（InterruptedException）——明确要求调用方响应中断信号，而非静默忽略
它容易出问题的地方：业务分层与函数式编程
一旦脱离底层资源交互，进入服务编排、领域逻辑或高阶抽象，Checked Exception就开始拖累设计。
- 服务方法写 public Order createOrder(...) throws SQLException, IOException —— 调用方被迫知道你用了数据库还是缓存，违反封装
- Stream 处理中写 map(s -> Files.readString(Path.of(s))) —— 编译直接报错，因 Function 不允许抛 Checked Exception
- 自定义 OrderProcessingException extends Exception 被 Dubbo 序列化后只剩 message，类型信息丢失，前端无法区分“库存不足”和“支付超时”
现代实践中的替代与平衡策略
不否定 Checked Exception 的初衷，而是用更贴合分层和通信约定的方式承接它的核心诉求——明确错误语义、推动责任落实。
- 框架层做异常翻译：Spring 把 SQLException 转为 DataAccessException（RuntimeException），再由 @ControllerAdvice 统一转成 HTTP 状态码 + 错误码
- 业务层用运行时异常承载语义：如 InsufficientBalanceException，构造时传入 ErrorCode.BALANCE_INSUFFICIENT，含状态码、提示语、重试建议
- 对外暴露统一响应体：{ "code": 4001, "msg": "余额不足", "traceId": "xxx" }，前端只认 code，不关心 Java 异常类型
- 工具方法封装兜底：提供 IoUtils.readStringSafely(path) 返回 Optional<String>，把“是否读到”变成值语义，而非异常控制流
本质上，Checked Exception 的强制力在今天更多被“显式契约”取代：不是靠编译器报错，而是靠接口文档、错误码规范、全局异常处理器和监控告警来确保关键错误不被忽略。它没过时，只是适用边界比过去更清晰了。
