UncheckedIOException 是什么，为什么 Stream 里会冒出来
它本质是 IOException 的包装器——把本该强制处理的受检异常（IOException）转成无需 try/catch 或 throws 声明的运行时异常。Java 8 引入它，**专为函数式 IO 场景服务**，比如 Files.walk()、Files.lines() 这些返回 Stream 的方法。它们内部读文件/遍历目录时一旦出错（如权限不足、路径循环、设备断开），就抛 UncheckedIOException，而不是让你在 lambda 里硬塞 try/catch。
常见错误现象：Files.walk(Paths.get("/bad/path")).forEach(...) 看似没写异常处理，一跑就崩，堆栈里出现 UncheckedIOException；或者用 map 解析某行文本时，底层 BufferedReader 已关闭，也抛这个。
怎么在 Stream 中捕获并安全终止
关键点：**异常不会在流构建时抛出，而是在终端操作（如 forEach、count、collect）执行过程中触发**。所以不能靠在 map 或 filter 里加 try/catch 捕获——那只能抓自己逻辑里的异常，抓不到底层 IO 异常。
- 最直接的做法：把整个终端操作包进
try/catch，例如try { stream.forEach(...); } catch (UncheckedIOException e) { log.warn("IO error during walk", e); } - 想“立即停止”？没问题——
UncheckedIOException是运行时异常，抛出即中断当前流消费，后续元素不会处理 - 别试图用
onClose()或tryAdvance()拦截，这些不接管异常传播路径
能不能把 UncheckedIOException 转回 IOException 处理
可以，但通常没必要。如果你的业务逻辑要求统一用受检异常兜底（比如已有成熟 IOException 处理链），可以手动解包：
立即学习“Java免费学习笔记（深入）”；
try {
Files.walk(path).forEach(...);
} catch (UncheckedIOException e) {
throw e.getCause() instanceof IOException
? (IOException) e.getCause()
: new IOException("Wrapped error", e);
}
注意：e.getCause() 就是原始的 IOException，直接强转安全。但这么做会破坏函数式风格的简洁性，且多数场景下，记录日志 + 中断流已足够。
和普通 RuntimeException 有什么区别
区别就在语义和可追溯性：UncheckedIOException 明确告诉你——这不是空指针或逻辑错，而是 **IO 层出了问题**。JVM 不会把它当普通 RuntimeException 忽略，IDE 和监控工具能识别其来源（比如 Spring Boot Actuator 的 health check 会区分 IO 类异常）。滥用其他 RuntimeException 替代它，会让问题定位变模糊。
容易踩的坑：
• 把 UncheckedIOException 当作可以忽略的“小异常”——它往往意味着路径不可达、磁盘满、NFS 挂载失效等真实环境故障
• 在自定义 Supplier<stream></stream> 或 Spliterator 里手动抛这个异常，却没设好 cause，导致根因丢失
• 用 Stream.iterate 或 generate 模拟文件流时，误以为需要抛它——不需要，那是你自己的逻辑，按需抛 IOException 或自定义异常即可
真正难的不是捕获，而是判断该不该继续——比如遍历日志目录时遇到一个损坏文件，是跳过还是中止？这得看业务契约，UncheckedIOException 只负责把 IO 错误干净地抬到流边界上，剩下的决策，得由你来定。
