@SneakyThrows 是编译期字节码增强，不改变异常模型，仅自动插入 try-catch 并抛出 RuntimeException；调用方仍需处理异常，且 IDE 不提示 throws，易致运行时崩溃与排查困难。
为什么 @SneakyThrows 看起来像能绕过编译检查，其实只是编译期“障眼法”
它不改变 JVM 的异常模型，也不让检查异常变成运行时异常；而是用字节码操作，在编译后把 try-catch 块悄悄塞进去，再原样抛出。所以调用方依然要处理该异常——除非你把它扔给上层方法签名甩锅。
常见错误现象：IOException 被 @SneakyThrows 包裹后，IDE 不报错、编译通过，但运行时遇到文件不存在仍会崩，且调用链上没声明 throws，排查时容易误以为“这里不可能抛异常”。
- 只对当前方法体生效，不影响方法签名，调用方看不到任何 throws 提示
- 默认捕获
Throwable，但你可以指定类型，比如@SneakyThrows(IOException.class) - 若方法已有
throws声明，Lombok 不会帮你合并，两者共存时以显式声明为准
@SneakyThrows 和手动 try-catch 在字节码层面有啥区别
本质一样：都是把受检异常转成未检查方式抛出。区别在于 Lombok 生成的 catch 块直接 throw new RuntimeException(e)（或包装为 RuntimeException 子类），而你自己写可能用 throw new UncheckedIOException(e) 或干脆 throw e（后者在 Java 7+ 允许，因 throw 语句的类型推断机制）。
性能影响几乎可忽略，但堆栈跟踪里会多一层 SneakyThrows 生成的代理调用，调试时可能看到类似 com.sun.proxy.$ProxyXX 或匿名内部类行号。
- 手动写
throw e更透明，但要求 JDK 7+ - Lombok 版本低于 1.18.20 时，对泛型异常（如
MyException<t></t>）支持不稳，可能编译失败 - 某些静态分析工具（如 ErrorProne）会警告 Lombok 插入的异常包装行为，需额外配置白名单
哪些场景真适合用 @SneakyThrows，哪些纯属自找麻烦
适合：工具方法中「本不该失败但又不得不声明」的 IO/反射调用，比如读取 classpath 下固定配置文件、获取当前类名、调用 Method.invoke() 且已确保参数安全。
不适合：业务主流程、对外 API、需要明确异常分类处理的地方。强行用它会让调用方失去对故障类型的感知能力。
- ✅ 适合：
ObjectMapper.readValue(getClass().getResourceAsStream("/config.json"), Config.class) - ✅ 适合：
Thread.currentThread().getContextClassLoader().loadClass("xxx") - ❌ 危险：
new URL("https://api.example.com").openConnection()—— 网络异常必须被看见和重试 - ❌ 危险：在 Spring
@Service方法里用它吞掉SQLException，事务切面可能无法正确回滚
IDE 和构建环境里容易被忽略的三个兼容性点
不是加了注解就自动生效，Lombok 需要编译器插件配合，否则你的 @SneakyThrows 就是段普通注释。
- IntelliJ 必须安装 Lombok plugin 并开启
Enable annotation processing，否则代码补全和跳转会失效 - Maven 构建需确认
lombok依赖 scope 是provided，且maven-compiler-plugin版本 ≥ 3.8.0（旧版不识别新 Lombok 字节码注入） - 使用 Gradle 时，若启用了
compileJava { options.fork = true }，需额外添加jvmArgs = ['-javaagent:lombok.jar']，否则注解无效
最常被漏掉的是 IDE 缓存——改完 Lombok 配置后，不重启 IDE 或不清缓存，就一直显示“找不到符号”，其实编译本身没问题。
