@SneakyThrows通过编译期字节码操作将受检异常强制转为RuntimeException抛出，绕过javac检查；需正确配置Lombok、作用于具体方法且匹配异常类型，避免滥用破坏API契约与异常可追溯性。
为什么 @SneakyThrows 能绕过编译器对受检异常的检查
Java 编译器强制要求调用受检异常（Exception 及其子类，但不包括 RuntimeException）的方法时，要么用 try-catch 捕获，要么在方法签名中用 throws 声明。@SneakyThrows 的本质不是“删除异常”，而是利用泛型类型擦除和字节码操作，在编译后把受检异常伪装成运行时异常抛出，从而骗过 javac 的语法检查。
它底层靠 Lombok 在编译期生成类似这样的字节码逻辑：throw (RuntimeException) new IOException("...") —— 这在源码层面不合法，但字节码里是允许的。
- 仅对 javac 有效；IDE（如 IntelliJ）可能仍报红，需开启 Lombok 插件并启用 annotation processing
- 不能用于构造函数或静态初始化块（Lombok 1.18.24+ 已支持部分场景，但仍有边界）
- 若异常实际被上层捕获为
Exception，运行时类型仍是原始受检异常类（比如IOException），只是逃过了编译检查
@SneakyThrows 怎么用才不会触发编译失败或 IDE 报错
最常见失败原因是注解没生效，或者用错了位置。它必须作用于**具体方法**（或构造器），且该方法体内确实有抛出受检异常的语句。
- 确保已添加 Lombok 依赖：
org.projectlombok:lombok，且构建工具（Maven/Gradle）配置了 annotation processor - IDE 必须安装对应插件（IntelliJ：Lombok Plugin；Eclipse：lombok.jar drag into eclipse.ini）
- 不要写成
@SneakyThrows(IOException.class)后又在方法里抛SQLException—— 默认捕获所有受检异常；若指定类型，必须严格匹配 - 避免在 lambda 表达式或方法引用中直接使用；它只修饰声明的方法，不穿透到内联代码
正确示例：
立即学习“Java免费学习笔记（深入）”；
import lombok.SneakyThrows;
public class FileReader {
@SneakyThrows
public String read(String path) {
return java.nio.file.Files.readString(java.nio.file.Paths.get(path));
}
}
什么时候不该用 @SneakyThrows
它解决的是“语法冗余”，不是“异常设计问题”。滥用会让调用方完全意识不到潜在失败点，尤其在公共 API 或跨团队模块中。
- 方法契约需要明确暴露 I/O 风险（例如 DAO 层的
loadUserById()）—— 此时应保留throws IOException或包装为自定义业务异常 - 异常需要被统一拦截处理（如 Spring 的
@ControllerAdvice）—— 若被 Sneaky 抹掉声明，全局异常处理器收不到IOException - 日志、监控、链路追踪依赖异常类型做分类 —— 运行时类型虽保留，但编译期不可见，静态分析工具（如 Sonar）会告警“隐藏异常”
- 与 Kotlin 互操作时，Kotlin 会把被 Sneaky 处理的 Java 方法视为“不抛异常”，一旦运行时炸了，Kotlin 端毫无防备
替代方案：比 @SneakyThrows 更可控的写法
如果只是嫌 try-catch 冗长，又不想牺牲可读性或破坏契约，可以封装一层小工具函数。
- 用
Unchecked工具类包装：写一个Unchecked.function(() -> Files.readString(p))，内部做try/catch+throw new RuntimeException(e)，调用方一眼看懂这是“转义”行为 - 用 Java 8+ 的
java.util.function.Function+ 包装接口，把受检异常声明移到函数式接口里（如ThrowingFunction<t extends exception></t>），再通过默认方法转成普通Function - Spring 用户可直接用
org.springframework.util.unit.FileCopyUtils等已做异常转换的工具类，避免自己造轮子
真正难的不是让代码编译过去，而是让下一个读它的人，在三秒内判断出“这里可能因为磁盘满而失败”。@SneakyThrows 把这个成本悄悄转嫁给了维护者。
