Java接口中声明受检异常会破坏API渐进式兼容升级，因其强制绑定调用方编译行为、固化语义并限制演进；应改用继承RuntimeException的统一异常（如CommonException），通过错误码和契约管理保障兼容性。
Java接口中声明受检异常（checked exception）会直接绑定调用方的编译期行为，与API契约的渐进式兼容升级目标天然冲突。真正影响升级稳定性的不是异常类型本身，而是它如何固化接口语义、限制演进空间。
受检异常让契约“刚性化”
一旦接口方法签名写明 throws ValidationException, IOException，所有实现和调用方就被强制卷入该异常体系：
- 新增一种业务错误，就得改接口、改所有实现、改所有调用方的 try-catch —— 违背开闭原则
- 下游 SDK 封装时无法统一转换异常，客户端被迫感知底层技术细节（比如数据库异常、网络超时）
- 版本升级时若想把
ValidationException替换为更细粒度的UserEmailInvalidException，就构成破坏性变更
运行时异常才是契约友好的载体
将业务错误建模为继承 RuntimeException 的统一异常（如 CommonException），才能解耦语义与实现：
- 接口方法保持干净：
UserDTO getUserById(String id)，不暴露异常细节 - 错误语义由 code + msg 承载，通过 OpenAPI 文档或 SDK 明确定义，而非编译器强制
- 版本升级只需扩展错误码枚举，旧 code 的含义不变，下游解析逻辑完全不受影响
兼容升级的关键不在 throws，而在契约管理
保障 API 升级不中断，靠的是分层验证与语义约定，不是靠接口抛什么异常：
- 用 Pact 或 Spring Cloud Contract 做消费者驱动契约测试，确保字段增删、类型变更不破坏已有交互
- 在 OpenAPI 中明确标注哪些字段是可选的、哪些枚举值已废弃，而非依赖 Java 方法签名约束
- 对接老系统时，用适配器封装受检异常：捕获
SQLException后转成CommonException(5001, "查询失败")，对外仍提供无 throws 的干净接口
把异常当成契约一部分来设计，反而会锁死演进路径。真正的兼容性，来自清晰的错误码体系、稳定的响应结构和前置的契约验证机制。
