非受检异常不可用于隐式触发自适应熔断，因其本质是暴露逻辑缺陷而非自动兜底；熔断应依赖实时指标与显式契约，通过可观测性体系统一采集、归一化失败事件并动态决策。
非受检异常本身不支持“隐式冒泡”作为设计特征——它只是不被编译器强制捕获，但其传播行为仍是显式的、可追踪的、遵循调用栈的。把“隐式冒泡”当作可用机制来构建自适应熔断，属于对 Java 异常模型的误读，容易导致故障不可见、状态不一致、恢复逻辑断裂。
非受检异常的本质是“早暴露、早修复”，不是“自动兜底”
NullPointerException、IllegalArgumentException 等非受检异常，设计初衷是揭示代码逻辑缺陷：空值未校验、参数越界、状态非法。它们在调用链中向上抛出，不是为了被层层忽略，而是为了让问题在离源头最近的位置被拦截和修正。若刻意依赖其“不强制捕获”的特性来触发熔断，相当于把 bug 当作开关——既掩盖真实缺陷，又让熔断决策失去语义依据。
真正支撑自适应熔断的是可观测性 + 显式契约，而非异常类型
自适应熔断依赖实时指标（错误率、延迟分布、请求数）和统计模型（滑动窗口、动态阈值、半开探测），这些必须由监控探针、指标采集器、策略引擎协同完成。它不关心抛出的是 RuntimeException 还是 IOException，只关心“这个服务在最近 60 秒内失败了 42% 的请求”。因此：
- 应在 RPC 客户端或网关层统一拦截所有失败响应（含超时、连接拒绝、5xx、业务错误码），归一化为可统计的“调用失败事件”
- 将非受检异常（如因序列化失败抛出的 IllegalArgumentException）包装为带上下文的领域异常（如 SerializationFailureException），并上报至熔断指标管道
- 禁止在 service 层 catch RuntimeException 后静默返回默认值——这会污染指标，让熔断器误判服务“看似健康”
可在领域层用非受检异常表达熔断决策结果，但需严格约束
当熔断器判定服务不可用，进入 OPEN 状态后，后续请求应快速失败。此时可抛出一个明确语义的非受检异常，例如：
- CircuitBreakerOpenException：继承 RuntimeException，携带熔断实例名、最后失败时间、fallback 是否可用等字段
- 该异常只在熔断执行层（如 Resilience4j 的 CircuitBreaker.decorateSupplier）中抛出，不用于业务逻辑判断
- 全局异常处理器将其转为标准 HTTP 503 或 gRPC UNAVAILABLE，并记录 traceId 与熔断状态快照
替代“隐式冒泡”的可靠路径：声明式降级 + 可观测熔断
更健壮的做法是脱离异常传播机制，改用显式控制流：
- 在接口契约中标注 [[circuit-breaker: account-service, fallback: local-cache]]，由 AOP 或 SDK 在运行时注入熔断逻辑
- 所有外部调用封装为 CompletionStage 或 Mono，失败时由框架统一触发 fallback 并更新熔断器状态计数器
- 通过 OpenTelemetry 自动注入熔断状态标签（circuit.state=OPEN），使 Prometheus 指标与日志、trace 关联可查
把非受检异常当作熔断触发器，就像靠程序崩溃来启动消防喷淋——它确实能停掉火，但代价是整个楼层被水淹。自适应熔断需要的是精准感知、可控干预、闭环验证，而不是对异常传播路径的被动依赖。
