先说结论：受检异常在复杂系统中并不适合作为跨层、跨服务传递错误信息的工具。其编译期强制约束机制，在RPC、序列化、异步等场景下必然出现断裂。更推荐的做法是建立统一的错误码体系，仅在单体应用内部、契约关系极紧密的少量场景中有条件地使用受检异常。
深入分析受检异常（Checked Exception）在分布式或分层架构中的传播机制，可以发现它并非运行时的自然通路，而是编译器强制规定的“人为链路”。其最大问题在于遇到进程边界、序列化边界或语言边界时，容易失效甚至断裂，同时增加不必要的耦合。因此，分析其传播路径的关键不是追踪它能够传播多远，而是要明确它在哪些节点无法通过以及为何需要被拦截。
受检异常传播路径受限于编译契约，而非运行时拓扑
Java编译器对受检异常有严格约束：若方法声明抛出Checked Exception，则调用方必须通过try-catch处理或继续向上throws。这一机制导致其传播范围局限于源码可见的直接调用链内，例如Service层调用Controller层。一旦超出单进程范围——如跨RPC调用、MQ消息投递、JSON/Protobuf序列化传输，甚至Java服务调用Go服务——受检异常将彻底失效，表现为序列化失败、反序列化报错，或被框架隐式转换为RuntimeException。
- 例如，订单服务抛出
InsufficientStockException extends Exception，通过Feign客户端调用库存服务时，该异常无法原样返回。Feign默认将其封装为FeignException——一个Unchecked异常。 - 又如，Kafka生产者将Checked Exception信息写入消息体，消费者反序列化时因类路径不匹配而抛出
ClassNotFoundException，导致原始业务含义丢失。
简而言之，受检异常如同被编译器赋予“铁布衫”的信使——在单机单进程内可以畅通无阻，但一旦跨越进程边界，反而成为障碍，无法有效传递。
典型断裂点：三层架构中常见的异常丢失场景
在分层架构中，受检异常往往在以下环节被隐式截断或替换，形成传播断点：
- 网关/协议层：Spring Cloud Gateway、API网关等组件遇到后端抛出的Checked Exception，会统一映射为HTTP 500响应，原始异常类型和堆栈信息完全丢失。
- 序列化层：Dubbo、gRPC等RPC框架对Checked Exception不友好，强制要求定义Error Code和Message字段，否则抛出
SerializationException，导致难以定位问题。 - 异步任务层：通过线程池提交Callable任务时，若call()方法抛出Checked Exception，会被
ExecutionException（Unchecked异常）包裹，上游无法按原类型捕获。
最佳实践：使用语义化错误码替代受检异常传播
构建复杂系统时，建议放弃让受检异常跨层传播的尝试，转而建立统一的、语义清晰的错误体系：
- 在接口契约中明确定义错误码（如
STOCK_UNAVAILABLE=1002）、错误消息模板及错误是否可恢复的标识。 - 每层仅抛出轻量级的非受检业务异常，如
BusinessException，内部封装错误码和上下文信息。 - 网关层或统一异常处理器将这些业务异常映射为标准响应结构（包含code、message、traceId），便于前端或下游服务准确定位和处理。
如此，异常如同被装入标准化“快递箱”，无论通过RPC、序列化还是异步任务传递，信息均不会丢失，处理逻辑清晰统一。
例外场景：单体应用内部强契约流程中的合理使用
受检异常并非全无价值，其合理使用空间必须明确限定：仅在单体应用内部、调用方与被调用方高度可控且具备明确恢复逻辑的场景中使用。例如：
- 文件解析模块发现格式错误时，向业务层返回
InvalidFileFormatException，调用方可根据情况提示用户重新上传或修正格式。 - 配置加载器缺少必要属性时，抛出
MissingRequiredPropertyException，使系统在启动阶段立即失败，避免带病运行。
这些场景的特点是调用路径短、无网络或序列化干扰、恢复逻辑确定。仅在此类环境中，受检异常才能真正发挥其设计初衷。
