@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）支持不稳，可能编译失败
• 某些静态分析工具（如 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 或不清缓存，就一直显示“找不到符号”，其实编译本身没问题。