受检异常本身无运行时开销，性能损耗源于异常抛出后的堆栈跟踪生成、栈展开及配套日志/补偿逻辑；高频用作控制流、未缓冲I/O、过度细粒度catch、无意义层层上抛是主要瓶颈点。
受检异常本身对性能几乎没有直接影响，真正影响系统表现的是异常被抛出并实际处理的过程。只要不频繁触发异常路径，编译期强制检查不会拖慢运行速度。
受检异常的性能开销主要来自哪里
受检异常（如 IOException、SQLException）在编译阶段要求显式处理，但这只是语法约束，不产生运行时成本。真正的开销出现在以下环节：
- 异常对象创建：每次 throw 都会生成堆栈跟踪（StackTrace），这是最耗资源的操作；
- 栈展开（stack unwinding）：JVM需回溯调用链寻找匹配的 catch 块，嵌套越深，耗时越长；
- 日志或补偿逻辑执行：若在 catch 中做重试、事务回滚、远程通知等，这些操作本身比异常机制更重。
什么情况下会触及性能边界
以下场景容易让受检异常成为性能瓶颈：
- 将异常用作控制流：比如用 FileNotFoundException 判断文件是否存在，而非先调用 File.exists()；
- 高频 I/O 场景中未做缓冲或批量处理，导致单次读写都可能触发异常；
- 数据库访问层对每个 SQL 执行都包裹独立 try-catch，且未统一异常转换，造成大量重复堆栈生成；
- 异常被层层向上抛出却无实际业务意义，最终只在顶层简单打印日志——既浪费资源又掩盖问题本质。
如何守住合理边界
关键不是避免使用受检异常，而是让它们出现在该出现的地方：
- 对外部可变因素（如网络、磁盘、用户输入）保持受检，体现契约意识；
- 对内部逻辑错误（如空指针、数组越界）不用受检异常包装，这类应通过校验提前拦截；
- 在循环或高频路径中，优先用返回码、Optional 或状态对象替代异常传递；
- 统一异常翻译层：将底层受检异常转为领域级非受检异常（如自定义 DataAccessException），减少传播深度。
安全与性能的交叉边界
忽略受检异常（比如仅写 catch (Exception e) { }）看似“省事”，实则越过两个关键边界：
- 语义边界：掩盖了本该由调用方决策的恢复策略（重试？降级？告警？）；
- 安全边界：可能让敏感错误信息泄露（如数据库连接失败时暴露完整 URL 或凭证片段）；
- 可观测性边界：静默吞掉异常会使监控指标失真，故障定位时间大幅延长。
