uncheckedioexception是lambda中处理io异常的合理选择，因其继承runtimeexception可绕过编译检查，又保留原始ioexception信息，支持getcause()提取真实异常，语义明确且利于排查。
为什么 UncheckedIOException 是 Lambda 里处理 IO 异常的合理选择
因为 Lambda 表达式要求函数式接口的抽象方法不能声明受检异常，而 IOException 是受检的——直接抛出会编译失败。用 UncheckedIOException 包装后，它继承自 RuntimeException，就能绕过编译检查，又保留原始异常信息。
它不是“吞掉异常”，而是把受检异常转成运行时异常，语义上仍表示 IO 故障，且能通过 getCause() 拿回原始 IOException。
- 别用
RuntimeException或IllegalArgumentException手动包装——丢失类型语义，后续统一捕获或日志分类会失效 - 不要在
try-catch里简单throw new RuntimeException(e)——UncheckedIOException显式表达了“这是 IO 问题”，对排查和监控更友好 - 注意：它只包装
IOException及其子类，传入SQLException会抛IllegalArgumentException
Files.lines() 配合 Lambda 读文件时怎么安全抛异常
Files.lines() 返回 Stream<string></string>，但底层打开文件流，一旦 IO 失败（如文件不存在、权限不足），必须在 lambda 中处理——而 map、filter 等操作不允许 throws IOException。
正确做法是在 lambda 内部用 UncheckedIOException 包装，再让异常自然向上冒泡：
立即学习“Java免费学习笔记（深入）”；
try (Stream<String> lines = Files.lines(Paths.get("data.txt"))) {
lines.map(line -> {
if (line.contains("ERROR")) {
throw new UncheckedIOException(new IOException("Invalid line format"));
}
return line.toUpperCase();
}).forEach(System.out::println);
} catch (UncheckedIOException e) {
// 这里能捕获，且 e.getCause() 是原始 IOException
System.err.println("IO problem: " + e.getCause().getMessage());
}
- 别在 lambda 外提前
Files.readAllLines()——大文件会 OOM，失去 stream 的懒加载优势 - 必须确保
Stream被正确关闭（用 try-with-resources），否则文件句柄泄漏 - 如果 lambda 中调用了其他可能抛
IOException的方法（比如ImageIO.read()），同样要用UncheckedIOException包装
Spring WebFlux 或 Stream API 中误用 UncheckedIOException 的典型错误
常见于想“静默吞掉 IO 异常”的场景，比如写一个工具方法返回 Optional<string></string>，却把所有异常都转成 UncheckedIOException 后又不处理，导致调用方收到未预期的运行时异常，甚至被框架当 500 错误返回。
- 不要在非 IO 上下文中滥用：比如解析 JSON 失败抛
JsonProcessingException，不该包成UncheckedIOException——它不是 IO 异常 - 不要在
flatMap或onErrorResume中无差别转换：WebFlux 的Mono.error(new UncheckedIOException(...))会让下游难以区分是网络超时还是磁盘满 - 日志中打印
e本身不够，必须显式输出e.getCause()，否则堆栈里看不到真实 IO 错误原因
替代方案对比：什么时候不该用 UncheckedIOException
它解决的是“Lambda 编译限制”这一个具体问题。如果项目已用 Vavr、Try、或者自己封装了 IOFunction<t></t> 接口，那没必要硬套这个类。
- 需要恢复性逻辑（比如重试、降级）时，用
Try.of(() -> Files.readString(p))比抛异常更可控 - 在单元测试中模拟 IO 失败，直接 mock 文件系统（如
MemoryFileSystem）比依赖异常抛出更可靠 - 如果团队约定所有 IO 操作必须显式声明失败路径，那就该重构接口，而不是用运行时异常绕过检查
最易忽略的一点：UncheckedIOException 的构造函数有多个重载，传错参数会导致 getCause() 为 null——务必用带 cause 的构造器，别只传 message。
