受检异常的强制捕获机制是框架演进中兼容性瓶颈的核心来源，因其导致跨版本api契约断裂、序列化与远程调用失配、测试与mock适配困难；现代框架转向以非受检异常为主、辅以错误码和结构化信息的设计。
受检异常的强制捕获机制，在框架演进中会成为兼容性瓶颈的核心来源之一。
跨版本API契约断裂
当框架升级时，若新增或移除某个受检异常类型，调用方代码将直接编译失败。例如旧版RPC客户端声明抛出 NetworkException（受检），新版改为 ConnectTimeoutException（同为受检但类名不同），所有调用处必须同步修改 catch 块并重新编译——这违背“向后兼容”原则。
- Java 编译器不认为
catch (NetworkException e)能覆盖新抛出的ConnectTimeoutException - 即使两个异常语义等价，只要不是继承关系，就无法被同一 catch 子句捕获
- 接口方法签名中 throws 子句变更属于破坏性修改，触发全链路适配成本
序列化与远程调用失配
分布式场景下，受检异常需跨进程传递，但其强耦合于具体类路径和版本。服务提供方升级异常类结构（如添加字段、改包名），消费方反序列化即失败：
-
ClassNotFoundException或InvalidClassException频发 - gRPC/Thrift 等协议默认不传输受检异常完整类型信息，仅靠错误码+消息字符串，丢失语义
- Spring Cloud OpenFeign 若未显式配置异常解码器，会把受检异常转为
FeignException，掩盖原始类型
测试与Mock框架适配困难
主流测试框架（JUnit 5、TestNG）对受检异常的支持逻辑固化，升级后易出现行为偏移：
- JUnit 4 的
@Test(expected = XXXException.class)在 JUnit 5 中已废弃，需改用assertThrows()，但后者不支持检查异常链 - Mockito 3.x 开始限制对受检异常的模拟：无法用
when(...).thenThrow(new MyCheckedException())直接抛出，必须包装为运行时异常 - 集成测试中，若框架内部将受检异常转为统一错误响应体，测试断言需同步重构，否则断言失效
替代方案更利于长期兼容
现代框架普遍转向非受检异常为主干设计，辅以结构化错误码与上下文信息：
- 统一定义
ApiException（继承RuntimeException），携带errorCode、traceId、details字段 - 通过 HTTP 状态码 + JSON body 传递业务错误，规避 Java 类型绑定
- 在 API 文档（OpenAPI）中明确定义错误响应 Schema，而非依赖 throws 声明
- 保留受检异常仅用于极少数必须强制处理的本地资源操作（如文件 I/O），且不暴露给跨服务接口
