受检异常的本质是编译期强制暴露不确定性并分层设计补偿路径。应通过throws声明向上暴露、自定义语义化子类、入口处集中调度补偿，避免吞异常或滥用@sneakythrows。
受检异常的编译强制提醒，本质是把“外部操作可能失败”这一事实固化进方法签名和调用链。它不是要你堆砌 try-catch，而是逼你在编译期就为不确定性设计明确的应对路径。利用好这一点，可以写出既简洁、又具备多级默认补偿能力的代码——关键不在捕获多少次，而在分层决策是否清晰。
用 throws 声明替代浅层空 catch，暴露可恢复点
很多开发者一看到编译报错，第一反应是加个 try-catch 把异常吞掉。这反而掩盖了真正的恢复机会。更合理的方式是让异常向上声明，把处理权交给更上层、信息更全的模块。
- 数据访问层只声明 throws SQLException，不自己重试或返回 null；
- 服务层看到这个 throws，就知道“数据库可能出问题”，于是主动引入缓存读取作为第一级 fallback；
- 若缓存也失效，再降级到静态配置或默认值——这些逻辑天然属于服务层职责，不应挤在 DAO 里。
按失败场景分级定义受检异常子类，驱动分支选择
不要只依赖 IOException 或 SQLException 这种宽泛类型。自定义语义明确的受检异常，能让调用方一眼识别失败性质，从而触发对应补偿策略。
- 比如定义 NetworkTimeoutException extends Exception（受检），表示可重试；
- 定义 DataCorruptedException extends Exception（受检），表示应跳过并记录告警；
- 方法签名写成 public Result fetch() throws NetworkTimeoutException, DataCorruptedException，调用方就能用多 catch 分别处理，而不是统一兜底。
在入口处集中做补偿调度，避免每层重复判断
把补偿逻辑收口到统一入口（如 Controller 方法或领域服务门面），利用编译强制确保每一类受检异常都被显式考虑过。
- Controller 方法声明 throws ExternalServiceException, ConfigLoadException；
- 用 AOP 或模板方法在调用前注册默认补偿器：超时自动重试 2 次，配置加载失败则启用内存中硬编码默认项；
- 这样业务方法本身保持干净，异常传播路径清晰，新增补偿策略只需改调度器，不碰原有逻辑。
慎用 @SneakyThrows，仅限确定不会发生的受检异常
当某个受检异常在当前运行环境中 100% 不会发生（如 SecureRandom.getInstance("SHA1PRNG") 在标准 JDK 中绝不会抛 NoSuchAlgorithmException），可用 @SneakyThrows 消除干扰，让真正需要关注的异常路径更突出。
- 它不取消异常语义，只是绕过编译检查，原始堆栈完整保留；
- 但绝不适用于 IOException、SQLException 等真实可能失败的场景；
- 滥用会导致本该被设计的补偿分支被悄悄跳过，违背受检异常的设计初衷。
