Lambda不能直接抛受检异常，因其必须匹配函数式接口方法签名（如Consumer.accept无throws）；@SneakyThrows可通过标注lambda参数或封装私有方法实现编译通过，适用于逻辑不可达（如UTF-8编码异常）或上层已兜底的场景。
不能真正“欺骗”，但可以通过正确方式让 Lambda 内部抛出受检异常且编译通过——关键不是绕过规则，而是适配函数式接口契约。
为什么直接 throw 不行
Lambda 表达式必须匹配函数式接口方法签名。像 Consumer.accept()、Runnable.run() 这些 JDK 内置接口的方法都没有 throws 子句，所以你在里面写 Files.readAllBytes()（抛 IOException）会直接编译失败。这不是语法限制，而是类型系统强制要求。
@SneakyThrows 在 Lambda 中的合法用法
它不能加在 lambda 外层方法上，也不能写成 @SneakyThrows list.forEach(...)——注解位置错，Lombok 不识别。有效方式只有两种：
- 在 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)
哪些受检异常适合这样处理
不是所有异常都适合“悄悄抛”。重点看是否真实可变、是否需要差异化响应：
- UTF-8 编码异常：new String(bytes, "UTF-8") 声明抛 UnsupportedEncodingException，但 JVM 规范强制支持 UTF-8，该异常逻辑上不可达
- Thread.sleep 的中断异常：若当前线程不会被中断（如非中断敏感的后台任务），InterruptedException 可视为冗余检查
- 上层已统一兜底：比如 Web 全局异常处理器能捕获所有 RuntimeException 并转为 500，底层把 SQLException 包装后抛出也合理
而 FileNotFoundException、SocketTimeoutException 这类真实发生、需重试或降级的异常，不建议用 @SneakyThrows 掩盖。
注意事项与常见陷阱
@SneakyThrows 是编译期字节码增强，不是魔法。它生成的其实是隐式 try-catch，再以 RuntimeException 形式重新抛出原始异常。这意味着：
- IDE 可能仍报红，需确保安装 Lombok 插件并启用 annotation processing
- 运行时异常类型仍是 IOException 等原始类型，只是逃过了编译检查
- 调用方看不到 throws 提示，容易误判“这里不会出错”，排查时堆栈里还多一层代理调用
- 不能用于静态初始化块或构造器（Lombok 1.18.24+ 对部分场景有支持，但仍有边界）
