Java Lambda不能直接抛受检异常，因需匹配函数式接口无throws声明的签名；推荐方案包括：try-catch包装为RuntimeException、提取为独立方法引用、定义带throws的自定义接口、使用Try容器。
Java 中 Lambda 表达式不能直接抛出受检异常，根本原因是它必须严格匹配函数式接口的抽象方法签名——而 Function、Consumer、Supplier 等 JDK 内置接口均未声明 throws 子句。这不是语法缺陷，而是类型系统对契约的强制约束。处理的关键是适配而非绕过，下面几种方式按场景推荐使用。
在 Lambda 内用 try-catch 包装为 RuntimeException
这是最常用、零依赖、编译安全的做法。核心是捕获后包装，保留原始异常作为 cause，不丢失堆栈信息。
- 写法要规范：用
throw new RuntimeException(e)，而不是throw new RuntimeException("msg")或只传e.getMessage() - 优先选用语义明确的子类：如
UncheckedIOException（针对IOException）、CompletionException（配合CompletableFuture） - 适合单点轻量操作，比如流中读一个文件、解析一段 JSON
提取为独立方法再引用
把含受检异常的逻辑封装成普通方法，Lambda 里只做方法引用。代码更清晰、可测试、易复用。
- 方法内部统一处理异常，例如：
private String readFile(String p) { try { return Files.readString(Paths.get(p)); } catch (IOException e) { throw new RuntimeException(e); } } - Stream 中调用简洁：
list.stream().map(this::readFile).forEach(...) - 便于加日志、监控埋点或统一重试策略
定义带 throws 的自定义函数式接口
当某类操作（如 IO、JSON、反射）高频出现时，从契约层面增强表达力，比隐式包装更可持续。
- 声明接口：
@FunctionalInterface interface ThrowingFunction{ R apply(T t) throws E; } - 提供工具方法转为标准接口：
static，内部自动 try-catch 并抛Function uncheck(ThrowingFunction f) RuntimeException - 调用端仍保持函数式风格：
stream.map(uncheck(path -> Files.readString(Paths.get(path))))
用 Try 容器（如 Vavr）替代异常传播
不中断控制流，把“可能失败”的操作建模为值对象，适合批处理、需要失败后继续执行的场景。
- Vavr 的
Try.of(() -> ...)自动捕获所有异常，返回Success或Failure - 支持链式操作：
map、recover、onFailure，避免嵌套 try-catch - 可与
Tuple2结合，同时携带结果和上下文（如错误码、日志 ID）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
