@SneakyThrows不消除受检异常，而是通过字节码改写将其伪装为运行时异常抛出；实际仍抛原始异常对象，故可被对应catch捕获；推荐显式指定异常类型，避免误吞；适用于测试、Lambda等场景，禁用于Service层等破坏契约处。
@SneakyThrows 不是“消除”受检异常，而是绕过编译检查，把 IOException、SQLException 这类异常“伪装”成运行时异常抛出去——它不改变异常本质，只改写字节码里的 throws 签名和 try-catch 结构。
为什么编译能过，但运行时还能 catch 到原始异常？
因为 @SneakyThrows 生成的字节码里，实际是包了一层 try { ... } catch (IOException e) { throw Lombok.sneakyThrow(e); }。而 Lombok.sneakyThrow() 底层靠泛型强制类型转换（throw (T) t）骗过编译器，JVM 层面抛出的仍是原 IOException 实例。
- 你用
catch (IOException e)依然能捕获，不是因为“被包装”，而是因为异常对象没变 - 但如果你只写
catch (Exception e)，就可能漏掉对特定异常的精细化处理 - IDE 和静态分析工具（如 SpotBugs）可能报“未声明的受检异常”，这不是 bug，是它们没集成 Lombok 编译插件
@SneakyThrows(value = {...}) 怎么选异常类型？
不指定 value 时，默认捕获所有受检异常；显式指定后，只拦截列表里的类型，其他受检异常仍会触发编译错误。
- 推荐始终显式指定，比如
@SneakyThrows(IOException.class)—— 避免意外吞掉本该处理的SQLException - 可以传多个类：
@SneakyThrows({IOException.class, InterruptedException.class}) - 不能写运行时异常（如
RuntimeException.class），Lombok 会忽略或报错 - 注意：如果方法里抛了未在
value中声明的受检异常，编译失败，不会静默跳过
哪些场景真适合用，哪些其实很危险？
它不是银弹，适用性极依赖上下文。
立即学习“Java免费学习笔记（深入）”；
- ✅ 安全场景：测试方法、Lambda 表达式（
Files.list(...).forEach(path -> { String s = Files.readString(path); })）、工具类中“理论上不会失败”的调用（如new String(bytes, "UTF-8")） - ✅ 合理场景：接口实现被迫继承 throws 签名（如
Runnable.run()），但内部确实只抛IOException - ❌ 危险场景：Service 层业务方法——调用方无法从方法签名得知可能抛什么异常，破坏契约，增加排查成本
- ❌ 危险场景：资源打开/关闭逻辑（如
FileInputStream构造 +read()）——两个地方都可能抛IOException，但只标注一个位置容易误判异常来源
最常被忽略的一点：它和 @Cleanup 经常一起用，但两者解决的是不同问题——@Cleanup 管资源释放，@SneakyThrows 管异常声明。合用时务必确认：你不是在用“简洁”掩盖“异常处理缺失”。
