@sneakythrows 会将受检异常包装为 runtimeexception（如 undeclaredthrowableexception）绕过编译检查，导致调用方无法感知异常、破坏契约、掩盖业务语义、引发运行时崩溃且难以排查。
使用 Lombok 的 @SneakyThrows 直接抛出受检异常（checked exception），会让调用方完全感知不到该异常的存在，破坏 Java 异常契约，极易引发运行时崩溃且难以排查。
绕过编译器检查，但没绕过 JVM 规则
@SneakyThrows 本质是通过字节码操作，把受检异常包装成 RuntimeException（默认是 UndeclaredThrowableException）再抛出，从而躲过编译期的 throws 声明校验。但 JVM 运行时仍会真实抛出异常——只是类型变了，调用栈里看不到原始异常类型，IDE 和静态分析工具也无法提示需要处理。
- 原始代码写的是
throw new IOException();，编译后变成throw new UndeclaredThrowableException(new IOException()); - 调用方若未捕获任何异常，程序直接终止，且堆栈中异常类型与业务语义脱节
- 日志或监控系统按异常类型做分类告警时，会漏掉这类“伪装”异常
掩盖异常意图，破坏接口契约
受检异常是 API 设计者明确传达的“调用者必须应对的失败场景”。比如 Files.readAllBytes(Path) 声明 IOException，就是在告诉使用者：文件可能不存在、权限不足、磁盘已满。用 @SneakyThrows 消掉这个声明，等于把关键错误信号静音。
- 下游开发者无法基于方法签名做防御性编程（如重试、降级、用户提示）
- 单元测试容易遗漏异常路径，因为编译器不强制要求
try-catch或throws - 重构时若将该方法提取为公共 API，隐患会被扩散到更多模块
替代方案：显式处理或合理转换
真正安全的做法不是隐藏异常，而是让异常以可理解、可捕获、可追溯的方式暴露出来：
- 在方法内直接处理（如记录日志 + 返回默认值/空对象），适用于非关键路径
- 封装为统一的、有业务含义的运行时异常（如
FileLoadFailedException extends RuntimeException），并保留原始 cause - 若确实需保持受检异常语义，就老老实实加
throws IOException，让调用方决定如何响应 - 必要时配合
@SneakyThrows(IOException.class)并在 javadoc 明确标注“此方法可能抛出 IOException”，但仍是权宜之计
团队规范建议
除非极少数内部工具类且全团队共识，否则应禁止在 public 方法或跨模块接口上使用 @SneakyThrows 处理受检异常。CI 流程中可用 ArchUnit 或自定义 Checkstyle 规则扫描 @SneakyThrows + 受检异常类型组合，自动拦截高风险用法。
不复杂但容易忽略：异常不是噪音，是设计语言的一部分。沉默的异常，比报错更危险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
