lambda中不能直接抛受检异常，因函数式接口方法未声明throws；@sneakythrows可绕过限制，但须正确作用于lambda本身或封装方法，且仅适用于逻辑上不可达或已统一兜底的异常。
在 Lambda 表达式里直接抛出受检异常（Checked Exception）会编译失败，因为函数式接口的抽象方法通常没声明 throws 子句。这不是语法限制，而是 Java 类型系统对函数签名的硬性要求。@SneakyThrows 能绕过这一限制，但关键在于用法要准、场景要对。
为什么 Lambda 里不能直接 throw 受检异常
函数式接口（如 Runnable、Consumer、Function）的方法签名是固定的。比如：
-
Runnable.run()返回 void，不带 throws； -
Consumer.accept(T)同样不声明任何异常。
当你写 list.forEach(item -> Files.readAllBytes(Paths.get(item)))，而 readAllBytes 抛出 IOException（受检异常），编译器立刻报错——Lambda 无法匹配接口契约。你既不能改接口，也不能让 JDK 为你加 throws，只能在代码层面“适配”。
@SneakyThrows 在 Lambda 中的正确写法
它不能直接加在 Lambda 外部方法上，必须作用于 Lambda 表达式本身或其封装方法。常见有效方式有两种：
- 在 Lambda 参数前加注解：
list.forEach(@SneakyThrows item -> { Files.readAllBytes(Paths.get(item)); }); - 提取为带注解的私有方法：
private @SneakyThrows void process(String path) { Files.readAllBytes(Paths.get(path)); }，再调用list.forEach(this::process)。
注意：不要写成 @SneakyThrows list.forEach(...)——注解位置错误，Lombok 不识别。
哪些受检异常适合用 @SneakyThrows 处理
不是所有受检异常都适合“偷偷抛”。重点看三点：是否可恢复、是否真可能出错、是否上层有意捕获。
-
明确不会发生的异常：比如
new String(bytes, "UTF-8")抛UnsupportedEncodingException——JDK 保证 UTF-8 必支持，此时用@SneakyThrows(UnsupportedEncodingException.class)合理； -
资源类中“必然成功”的操作：如
Thread.sleep(100)的InterruptedException，若当前线程绝不会被中断，可视为逻辑上不可达； -
上层已统一兜底的场景：比如 Web 层全局异常处理器能捕获
RuntimeException并转为 500 响应，那底层把SQLException包装后抛出也无妨。
反之，像文件不存在（FileNotFoundException）、网络超时（SocketTimeoutException）这类真实可变、需差异化处理的异常，不建议用 @SneakyThrows 掩盖。
替代方案与风险提醒
@SneakyThrows 是便利工具，不是异常治理方案。它生成的代码本质是：
try { /* your code */ } catch (IOException e) { throw new RuntimeException(e); }
这意味着：
- 原始异常类型丢失（堆栈里是
RuntimeException包裹的），上层用catch (IOException e)捕不到； - 如果没配置全局异常处理器，可能导致 silent fail 或难以定位的 500；
- 过度使用会让异常流变得隐晦，新成员读代码时容易忽略潜在失败点。
更透明的做法包括：自定义函数式接口（如 ThrowingConsumer<t e extends exception></t> + 静态适配方法），或用 Vavr、cyclops 等库提供原生支持。但若团队已接受 Lombok 且场景可控，@SneakyThrows 仍是简洁有效的选择。
