根本原因是受检异常无法跨进程、跨语言、跨序列化边界安全传递，强行使用会导致契约断裂、语义丢失、调用方编译失败或运行时崩溃；其依赖java特有编译机制与类定义完整性，在rpc场景下易因类缺失、序列化不兼容、版本不一致及多语言不可识别等问题失效，主流框架亦会将其降级为通用异常而丢失业务语义。
RPC 接口设计中不能抛出自定义受检异常，根本原因在于：**受检异常无法跨进程、跨语言、跨序列化边界安全传递，强行使用会导致契约断裂、语义丢失、调用方编译失败或运行时崩溃**。
序列化与类加载不兼容
受检异常是 Java 特有的编译期机制，依赖完整的类定义和继承关系。在 RPC 场景下：
- Provider 抛出的自定义受检异常（如
InsufficientStockException）需被 Consumer 反序列化，但 Consumer 很可能没有该类——类路径缺失直接触发ClassNotFoundException - Dubbo/gRPC 等框架默认只支持基础 JDK 异常或框架内置异常的序列化；自定义受检异常若未实现
Serializable或含不可序列化字段，会抛出SerializationException - 即使双方都有该类，版本不一致（如字段增删、serialVersionUID 不匹配）也会导致反序列化失败
接口契约被强绑定，阻碍演进
受检异常写入方法签名后，就成为硬性契约：
- 接口一旦声明
throws CustomBizException，所有实现类、代理类、客户端 stub 都必须适配该类型 - 升级时若修改异常类名、包路径或继承关系，整个调用链从 Provider 到 Gateway 再到前端 SDK 全部编译报错
- 多语言客户端（Go/Python/JS）完全无法识别 Java 的受检语义，既不能
catch，也无法映射为本地错误类型
RPC 框架自动降级，语义被抹平
主流框架对未声明或非标准异常有统一兜底策略，而非原样透传：
- Dubbo 默认将未在接口
throws中声明的异常包装为RpcException，原始堆栈和业务字段（如 error code、traceId）被丢弃 - Feign 将任何服务端异常转为
FeignException，只剩 HTTP 状态码和响应体字符串 - gRPC 使用
StatusRuntimeException，仅保留status.code和status.description，自定义异常的枚举字段、上下文数据全丢失
替代方案更健壮、更通用
真正可行的做法是放弃“抛异常”，改用显式错误表达：
- 接口返回值统一封装为
Result<t></t>，含code、message、data字段，错误信息走 body 而非异常机制 - 服务端内部可用运行时异常（如
BusinessException）组织逻辑，由全局 Filter 或 Interceptor 捕获并转为标准Result响应 - 网关层统一将 HTTP 4xx/5xx 或 RPC 错误码映射为前端可解析的错误结构，与语言无关
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
