@SneakyThrows 并未绕过编译器检查，而是通过 Lombok 在 AST 转换阶段将受检异常语句重写为 try-catch 块并包装为 RuntimeException，使编译器无法感知异常存在，本质是编译期静态改写而非 JVM 层面干预。
@SneakyThrows 并没有真正“绕过”编译器的受检异常检查机制，而是通过字节码层面的技巧，让编译器在编译时**不感知异常的存在**，从而避免强制声明或捕获。它的本质是 Lombok 在编译期（准确说是 AST 转换阶段）对代码做静态改写，把原本会抛出受检异常的方法调用，包裹进一个看似“不抛异常”的 try-catch 结构，并将异常原样抛出为 RuntimeException —— 而 RuntimeException 是非受检异常，编译器不强制处理。
核心原理：AST 改写 + 异常包装
Lombok 作为注解处理器，在 javac 解析完源码生成抽象语法树（AST）后、生成字节码前介入。@SneakyThrows 注解触发 Lombok 修改 AST：
- 找到被标注方法中所有可能抛出受检异常的语句（如
FileInputStream fis = new FileInputStream("a.txt");） - 将其重写为 try-catch 块：
try { /* 原语句 */ } catch (Exception e) { throw new RuntimeException(e); } - 注意：这里 catch 的是
Exception（或指定类型），而throw new RuntimeException(e)是非受检的，因此方法签名无需声明 throws，调用方也无需处理
为什么编译器“看不见”异常？
因为异常传播路径在源码层面已被切断：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 原始语句的 throws 声明（如
FileInputStream构造器声明 throws IOException）在 AST 中仍存在，但 Lombok 插入的 try-catch 把它“拦截”了 - 最终生成的字节码里，该方法的
throws属性（Signature）不包含任何受检异常类型 - javac 只校验源码 AST 和方法签名的一致性，而改写后的 AST 已满足“无未处理受检异常”的规则
关键限制与风险
这种处理是纯编译期技巧，运行时行为不变，但也带来隐含问题：
立即学习“Java免费学习笔记（深入）”；
- 调用栈中异常被包装了一层
RuntimeException，原始异常变成 cause，调试时需展开 getCause() - 无法针对特定受检异常做差异化处理（比如只捕获
IOException重试，而忽略SQLException） - 过度使用会削弱 Java 异常设计的意图——强迫开发者直面可恢复的受检异常
- IDE 或静态分析工具（如 IntelliJ、SonarQube）可能无法识别 Lombok 的改写逻辑，误报“异常未处理”
它不是 JVM 层面的绕过
有人误以为 @SneakyThrows 修改了 JVM 规范或字节码验证逻辑，其实不然：
- JVM 本身不限制抛什么异常，校验的是字节码结构合法性（如异常表是否匹配）
- Lombok 生成的字节码完全合规：try-catch 块存在，异常被 catch 后以 RuntimeException 形式 re-throw
- 没有用到 Unsafe、字节码注入或运行时代理等黑科技，纯粹是编译期代码生成
