受检异常是编译期强制处理的Exception子类（排除RuntimeException），javac在AST阶段静态检查未捕获/未声明的调用，异常信息写入字节码Exceptions属性，保障控制流完整性与接口语义明确性。
受检异常（Checked Exception）是Java语言中一项强制性的错误处理机制，它要求编译器在编译期就检查异常是否被显式处理——要么捕获（try-catch），要么声明抛出（throws）。这种设计初衷是提升程序健壮性，但实际落地时会带来不容忽视的性能与维护成本。
编译期强制带来的代码膨胀与耦合加深
每个受检异常都必须在方法签名中声明，导致调用链上所有中间层都要被动传播或处理该异常。这并非逻辑必需，而是语法约束：
- 方法接口被异常“污染”：一个底层I/O操作抛出IOException，可能迫使上层业务方法也声明throws IOException，即使它根本不关心文件细节；
- 产生大量样板代码：为满足编译要求，开发者常写空catch块、或仅记录日志后重新包装为运行时异常，削弱了异常语义；
- 接口演化困难：一旦底层API新增受检异常，所有调用方必须同步修改，破坏向后兼容性。
运行时开销虽小但不可忽略
相比运行时异常（RuntimeException），受检异常本身不额外增加JVM执行路径的分支判断，但其使用模式间接抬高成本：
- 异常对象构造开销：每次throw都会创建堆对象并填充栈轨迹（stack trace），而受检异常更常出现在I/O、网络等慢路径，易被频繁触发；
- 异常捕获逻辑影响JIT优化：JVM对try块内代码的内联和逃逸分析更保守，尤其当catch块存在时，可能抑制关键路径的深度优化；
- 异常链传递增加GC压力：多层包装（如new RuntimeException(e)）生成嵌套异常对象，延长对象存活周期，加重垃圾回收负担。
维护成本远高于技术成本
真正拖慢团队节奏的，往往不是毫秒级性能损耗，而是长期积累的可维护性债务：
- 异常处理逻辑分散：同一类错误（如连接超时）可能在不同模块用不同方式处理（重试/降级/告警），缺乏统一策略；
- 掩盖真实问题：为快速通过编译，开发者倾向“吞掉”异常或转为RuntimeException，导致故障无法在早期暴露；
- 测试复杂度上升：每个受检异常分支都需要对应单元测试覆盖，显著增加测试用例数量和维护成本；
- 新人理解门槛高：需同时掌握异常分类规则、传播原则、包装惯例，学习曲线陡峭。
合理控制受检异常影响的实践建议
不必全盘否定受检异常的价值，关键在于克制使用、明确边界：
- 只对**可恢复且调用方有责任响应**的错误使用受检异常（如SQLException——应用可能需回滚事务；InterruptedException——线程应尊重中断信号）；
- 将底层受检异常在适配层转换为语义清晰的运行时异常（如DAO层捕获IOException，抛出DataAccessException），隔离技术细节；
- 避免在领域模型或核心业务逻辑中声明受检异常，保持业务代码“干净”；
- 借助Lombok的@SneakyThrows等工具谨慎绕过编译检查——仅限明确知道风险且无更好方案的场景（如lambda中调用Thread.sleep()）。
