受检异常阻碍接口演进，因其将编译期契约强加于方法签名，导致接口脆弱、耦合加深、变更成本陡增；它锁定异常类型，使实现与调用方被迫绑定，升级时引发雪崩式修改，分布式场景下更造成语义失真与测试失效。
受检异常对接口演进构成实质性障碍，核心在于它把编译期契约强加于方法签名，使接口变得脆弱、耦合加深、变更成本陡增——不是“不好用”，而是“改不动”。
接口契约被异常类型锁定
一旦接口方法声明 throws 某个受检异常（如 SQLException），所有实现类和调用方就都被绑定在这个类型上：
- 实现类不能删掉该声明，哪怕实际逻辑已不再抛出——否则编译失败
- 若想细化为更具体的 SQLTimeoutException，调用方 catch 块必须同步更新，否则无法捕获
- 新增一个异常类型（如 ConfigLoadException），整条调用链从 DAO 到 Controller 都得追加 throws，哪怕中间层只是透传
跨版本升级引发全链路编译中断
框架或 SDK 升级时，受检异常的微小变动常触发雪崩式修改：
- 旧版 RPC 接口抛 NetworkException，新版改为语义等价但类名不同的 ConnectTimeoutException，调用方代码直接编译不过
- JDBC 驱动升级后，某方法不再抛 SQLFeatureNotSupportedException，但接口仍声明它，实现类无法自行移除，只能保留“幽灵异常”
- 微服务拆分时，原单体接口含多个受检异常，新服务边界难以干净切割，常被迫保留冗余声明以维持二进制兼容
序列化与远程调用导致语义失真
分布式场景下，受检异常无法自然跨进程传递，接口演进时极易出现“表面兼容、实际断裂”：
- 服务端升级异常类结构（如添加字段、改包名），消费方反序列化失败，报 ClassNotFoundException
- gRPC/Thrift 默认不传输受检异常完整类型信息，只靠错误码+字符串，原始异常语义完全丢失
- Feign 客户端未配异常解码器时，IOException 会被转成泛化的 FeignException，掩盖真实失败原因
测试与 Mock 适配滞后，重构验证失效
接口变更后，配套测试体系往往跟不上，导致演进缺乏安全护栏：
- JUnit 4 的 @Test(expected = XXX.class) 在 JUnit 5 中废弃，需改用 assertThrows()，但后者不支持检查异常链
- Mockito 3.x 起限制对受检异常的模拟，when().thenThrow(new MyCheckedException()) 直接报错，必须包装
- 集成测试中，若框架内部将受检异常转为统一 JSON 错误响应，原有基于异常类型的断言全部失效
本质上，受检异常让接口承担了不该承担的“异常治理职责”。现代演进策略普遍选择：在边界处收敛（如 DAO 层封装为 DataAccessException），对外暴露统一错误码与非受检异常，把接口真正回归到“定义行为”，而非“罗列失败清单”。
