Java接口不应声明受检异常，因其破坏契约稳定性、绑架调用方且违背开闭原则；应改用运行时异常承载业务错误语义，通过统一异常类、全局处理器、文档与SDK保障兼容性与解耦。

Java接口不该声明受检异常——这不是灵活性不够，而是设计目标错位。真正要解决的不是“怎么让接口兼容受检异常”，而是如何让错误语义清晰、稳定、可演进，同时不绑架调用方的编码习惯和编译约束。

接口声明受检异常会破坏三层契约稳定性

一旦在方法签名里写 throws ValidationException, IOException，就等于把实现细节强加给契约：

• 所有实现类必须显式处理或继续抛出，无法隐藏内部技术选型（比如数据库换为内存缓存后，还该抛 SQLException 吗？）
• 每个调用方都被迫写 try-catch 或向上声明，业务代码被异常模板淹没，可读性下降
• 新增一个业务错误类型（如 AccountFrozenException），就得改接口、改所有实现、通知所有下游——开闭原则形同虚设

运行时异常才是语义解耦的合理载体

用继承 RuntimeException 的统一异常类（如 CommonException）承载业务错误，接口保持干净：

• 方法签名不带 throws，实现自由选择何时、为何、以何种结构抛出异常
• 异常本身携带 code、msg、status 等字段，由全局异常处理器统一转成标准响应体
• 调用方按需捕获特定子类（如 UserNotFoundException），或统一处理 CommonException，粒度可控

兼容性靠文档与SDK，不靠 throws 关键字

所谓“兼容”，本质是错误语义的一致理解，而非编译期强制绑定：

• OpenAPI 文档明确定义各 HTTP 状态码对应哪些 error_code 及含义，前端/合作方据此解析
• 提供 Java SDK 封装远程调用：内部消化 HttpClientErrorException、TimeoutException 等受检异常，对外只抛业务意义明确的运行时异常
• 版本升级时只扩展错误码枚举，保留旧码语义不变，下游无需改任何解析逻辑

对接老系统时，用适配器吞掉受检异常

当必须集成遗留模块或第三方 SDK（其方法强制 throws SQLException、RemoteException）：

• 不修改对外接口定义，另写一层适配器实现该接口
• 适配器内部 try-catch 这些受检异常，转为 CommonException 并附带原始 cause
• 干净接口照常使用，脏活全由适配器消化，边界清晰、职责单一