受检异常应仅用于调用方有能力且有必要介入恢复的外部可恢复场景，如HTTP调用失败、数据库连接超时；参数校验失败等编程缺陷应抛非受检异常；需通过封装适配层收敛暴露面，统一异常处理机制替代分散捕获。
受检异常（Checked Exception）强制编译期处理，确实能提醒开发者关注外部风险，比如文件读取失败、网络超时等可恢复场景；但它也容易让代码被层层 throws 和 try-catch 割裂，降低可读性与维护效率。平衡的关键不是“用不用”，而是“在哪用、怎么用”。
明确区分异常语义：只对可恢复的外部问题用受检异常
受检异常应仅用于调用方有能力且有必要介入恢复的场景。例如：
- 调用第三方 HTTP 接口失败 → 可重试或降级，适合定义为
IOException或自定义受检异常 - 数据库连接超时 → 上层可切换数据源或返回缓存，也属合理使用范围
- 但参数校验失败（如手机号格式错误）、空指针、逻辑冲突等 —— 这些是编程缺陷或输入问题，应抛
IllegalArgumentException等非受检异常，靠前置校验规避，而非强迫调用方处理
用封装和适配层收敛受检异常暴露面
避免让业务代码直接面对 SQLException 或 ParseException 这类底层异常。推荐做法：
- 在 DAO 或 Client 层统一捕获原始受检异常，转换为语义清晰的业务异常（如
OrderNotFoundException），继承RuntimeException - 对外提供接口时，方法签名不声明底层受检异常，只抛出封装后的非受检异常，调用方无需
throws，但可通过文档或注释了解可能失败点 - 若必须保留受检特性（如 SDK 对接规范要求），则仅在最外层门面（Facade）或 API 入口处声明，内部实现完全隔离
谨慎使用 @SneakyThrows 简化不可达路径
对于确定不会发生的受检异常（如 UnsupportedEncodingException 在 UTF-8 硬编码场景），可用 Lombok 的 @SneakyThrows 消除冗余声明：
- 它不吞异常，只是绕过编译检查；真发生时仍以
RuntimeException形式抛出，堆栈完整，不影响调试 - 建议显式指定异常类型，如
@SneakyThrows(NoSuchAlgorithmException.class)，防止误掩其他异常 - 仅用于真正“不可能”触发的路径，不可滥用在 IO、网络等不确定性高的环节
统一异常处理机制替代分散 try-catch
与其在每个 service 方法里写一堆 try-catch 处理相同类型的受检异常，不如集中治理：
- Spring 项目可用
@ControllerAdvice + @ExceptionHandler统一捕获并转为标准响应体 - 自定义异常基类（如
BusinessException），所有业务失败都抛它，不再区分受检/非受检 - 日志、监控、告警通过异常类型自动分流，无需每处手动记录
本质上，安全性不来自“强制声明”，而来自“意图明确”和“边界清晰”。把受检异常留给真正需要协作恢复的环节，其余交给清晰的封装与统一的响应契约，代码就既健壮又干净。
