Optional不用于处理受检异常，其职责仅为表达值的存在性；正确方案是使用Try、Result等专门容器或函数式接口转译异常。
Optional 本身不用于处理受检异常（Checked Exception），它只负责封装“值是否存在”，和异常抛出、捕获、转换无直接关系。把 Optional 当作受检异常的解决方案，是一种常见误解。真正优雅处理受检异常的方式，是用 Result 容器（如 Vavr 的 Try、自定义的 Result<T, E>）或结合函数式接口做异常转译，而非强行套用 Optional。
Optional 不该承担异常处理职责
Optional 的设计目标非常明确：表达「一个值可能为空」的语义。它不持有异常信息，也不捕获、包装或传播受检异常。以下写法是错误且危险的：
-
❌ 错误示范：
Optional<InputStream> stream = Optional.ofNullable(openFile());—— 若openFile()声明 throws IOException，这段代码根本编译不过，因为受检异常未处理； -
❌ 误区滥用：
return Optional.ofNullable(result).orElseThrow(() -> new RuntimeException(e));—— 这掩盖了原始受检异常类型，丢失上下文，且违背 Optional 的语义（它本就不该承载异常逻辑）。
受检异常的合理封装：用 Result 或 Try 替代
当需要统一处理成功/失败路径，并保留异常类型信息时，应选用专门为此设计的容器：
-
Vavr Try：提供
Try.of(() -> riskyOperation())，自动捕获受检异常并转为Success<T>或Failure<Throwable>； -
自定义 Result<T, E extends Throwable>：显式区分成功值与具体异常类型，支持
map、flatMap、recover等链式操作； - Spring 的 ResponseEntity<T>（Web 场景）或 CompletableFuture<T>（异步场景）也常作为事实上的 Result 容器，配合异常回调使用。
必要时可桥接 Optional 与异常处理逻辑
Optional 可在「异常已处理完毕，仅需表达结果存在性」的环节辅助收尾，但必须确保异常已在上游被显式捕获：
- 先用 try-catch 或 Try 封装受检操作，得到一个确定的结果（可能是 null 或有效对象）；
- 再用
Optional.ofNullable(result)表达该结果是否有效，用于后续空值安全的链式转换（如map、filter）； - 例如：读取配置文件后解析 JSON，异常在解析层捕获并返回 null，则
Optional.ofNullable(jsonNode)可继续做字段提取，避免 NPE。
替代方案：用 Supplier + 函数式接口做异常转译
若无法引入第三方库，可用轻量方式将受检操作转为非受检形式：
- 定义工具方法：
<T> T uncheckedCall(ThrowingSupplier<T> supplier)，内部 catch 受检异常并包装为 RuntimeException； - 配合 Optional 使用示例：
Optional.ofNullable(uncheckedCall(() -> Files.readString(path)))； - 注意：此方式适合内部工具类或测试代码，生产环境仍建议保留原始异常类型以便诊断。
