受检异常不适宜跨层跨服务传播，因其编译期强制约束导致在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），交由前端或下游服务解析处理。
例外场景：仅限单体内部强契约流程
受检异常仍有合理存在空间，但严格限定于：单体应用内、调用方与被调用方高度可控、且恢复逻辑明确的场景。例如：
- 文件解析模块向业务层返回
InvalidFileFormatException，调用方可选择重试上传或提示用户修正格式； - 配置加载器抛出
MissingRequiredPropertyException，启动阶段立即失败，避免带病运行。
这类路径短、无网络/序列化介入、恢复动作确定，才真正发挥受检异常的设计本意。
