UncheckedIOException 是 Java 8 提供的专用于包装 IOException 的运行时异常，保留原始异常类型与上下文，需显式捕获后构造，禁止裸 throw 或用 RuntimeException 替代，仅限 IO 场景使用并配合资源管理。
UncheckedIOException 是 Java 8 引入的官方运行时异常，专为安全包装受检的 IOException 设计。它不绕过错误本身，而是绕过编译器对“必须显式处理”的强制要求，同时完整保留原始异常的类型、消息、堆栈和因果链（e.getCause() 可直接强转为 IOException）。
必须用 try-catch 显式捕获后构造
不能在 lambda 中裸 throw 新建的 UncheckedIOException，否则会丢失原始上下文；也不能用 new RuntimeException(e) 替代——这会抹掉语义信息，导致监控、日志分类或 instanceof 判断失效。
- ✅ 正确写法：在 lambda 内部先
catch (IOException e)，再throw new UncheckedIOException(e) - ❌ 错误写法：
throw new UncheckedIOException("read failed", e)—— 除非需补充额外上下文，否则默认构造器已足够 - ❌ 错误写法：
throw new RuntimeException(e)—— 类型丢失，e.getCause() instanceof IOException仍成立，但语义模糊
只包装明确的 IOException，不泛化捕获
UncheckedIOException 的构造器会对传入的 cause 做类型校验：若非 IOException 或其子类，会抛出 IllegalArgumentException。这是它的保护机制，也是设计意图的体现。
- 只在确定调用的是 IO 相关方法（如
Files.size()、ImageIO.read()、ObjectMapper.readValue()等可能抛IOException的场景）中使用 - 避免在同一个
catch块里捕获Exception或Throwable后统一包装——可能把NullPointerException也塞进去，违背语义 - 若需处理多种受检异常（如
SQLException+IOException），应分别定义对应 Unchecked 包装类（如UncheckedSQLException）
配合流操作时注意资源与异常传播边界
UncheckedIOException 不改变资源生命周期，也不影响流的延迟求值特性。异常发生时，流可能已打开文件句柄但未关闭，必须靠外部机制兜底。
立即学习“Java免费学习笔记（深入）”；
- 使用
Files.lines()或Files.walk()时，务必用try-with-resources包裹整个 stream，确保异常发生时自动 close - 不要提前调用
Files.readAllLines()再进 stream —— 失去懒加载优势，大文件易 OOM - 若需容错遍历（跳过权限不足目录），
Files.walk()默认会中断；此时应改用Files.walkFileTree()配合SimpleFileVisitor.visitFileFailed()，并在该方法中抛UncheckedIOException
捕获与诊断要保留原始异常线索
异常最终被 UncheckedIOException 包装后，仍应以可追溯的方式处理，而不是简单吞掉或打通用日志。
- 顶层统一 catch
UncheckedIOException，通过e.getCause()获取原始IOException，做针对性处理（如重试、告警、降级） - 日志记录时建议输出
e.getCause().toString()而非仅e.getMessage()，避免丢失异常类型和堆栈关键帧 - 监控系统或 APM 工具可基于
instanceof UncheckedIOException做 IO 类异常聚类，区别于空指针或业务校验失败
