@SneakyThrows 并非隐藏 throws 的黑魔法，而是通过字节码操作将受检异常包装为 RuntimeException 抛出，绕过编译器检查但不违反 JVM 规范，导致异常语义丢失且调用方无法按类型捕获。
@SneakyThrows 并不是“隐藏 throws”或“逃避编译器检查”的黑魔法，而是通过字节码层面的技巧，绕过 Java 编译器对受检异常（checked exception）的强制处理要求。它不修改源码语法，也不让 throws 关键字出现在生成的源代码里，而是在编译后生成的字节码中，把受检异常当作非受检异常（即 RuntimeException 的子类）来抛出——从而跳过编译期检查。
它不生成 throws 声明，也不修改方法签名
Lombok 的 @SneakyThrows 不会在反编译出的 Java 源码里添加 throws 子句，也不会改变方法的签名。它只是在编译时，用 ASM 等字节码操作工具，在生成的 .class 文件中：
- 将原本要声明为受检异常的
throw e，替换成包装成new RuntimeException(e)或类似方式重新抛出； - 确保该异常在字节码层面以
java.lang.RuntimeException（或其子类）形式抛出，而非原始的IOException、SQLException等； - 因为 JVM 运行时不要求捕获或声明
RuntimeException，所以调用方无需try-catch或throws，编译器也就不会报错。
本质是“欺骗编译器”，不是绕过 JVM 规则
Java 编译器的受检异常检查只作用于源码和 .class 的方法签名（Signature），而 JVM 本身并不区分受检/非受检异常——所有异常都是 Throwable。@SneakyThrows 利用了这一点：
- 它不违反 JVM 规范，所有异常仍正常抛出、可被捕获；
- 它只是让编译器“看不见”原始异常类型——因为在字节码里，抛出的是
RuntimeException，且方法签名没声明任何异常； - 如果你用 javap 查看生成的 class 文件，会发现
exceptions属性为空，没有throws条目。
实际效果：写法简洁，但异常语义丢失
例如这段代码：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
编译后等效于：
void readFile() { try { String s = Files.readString(Paths.get("a.txt")); } catch (Throwable t) { throw new RuntimeException(t); } }注意：
- 原始的
IOException被包裹进RuntimeException，堆栈中保留了 cause； - 调用者无法按类型捕获
IOException，只能捕获RuntimeException或更上层的Throwable； - IDE 和静态分析工具（如 ErrorProne）可能无法识别潜在的受检异常风险，容易掩盖问题。
它不是替代 try-catch，而是明确放弃编译期保障
@SneakyThrows 适合极少数场景：
- 你 100% 确定该异常绝不会发生（如
new String(bytes, "UTF-8")的UnsupportedEncodingException在现代 JDK 中已不可能）； - 或你愿意承担运行时崩溃风险，并接受异常类型信息丢失的代价；
- 不适合业务逻辑中真实的 I/O、网络、解析等可能失败的操作——那里应该显式处理或向上声明。
