timeoutexception是分布式调用中触发熔断与降级的关键信号，需显式注册为熔断异常、立即执行本地降级、分级设置超时策略，并统一处理框架包装的超时异常。
在分布式调用中，TimeoutException 不仅是超时信号，更是客户端发起主动熔断与降级的关键触发点。它代表下游服务响应迟缓或不可用，此时若继续重试或等待，会加剧资源耗尽和雪崩风险。因此，应将其视为一个明确的“健康状态告警”，驱动客户端立即执行熔断、切换备用逻辑或返回兜底数据。
将 TimeoutException 作为熔断器的状态输入源
主流熔断库（如 Resilience4j、Sentinel 或 Hystrix）均支持自定义异常判定规则。需显式将 TimeoutException 注册为“触发熔断的异常类型”，而非仅依赖失败率统计：
- Resilience4j 中，在 CircuitBreakerConfig 里通过 recordExceptions 添加
TimeoutException.class - Sentinel 中，通过 @SentinelResource 的 blockHandler 捕获降级，同时在规则中配置 exceptionToIgnore 以外的所有异常默认参与流控/熔断，TimeoutException 自然生效
- 避免仅靠“调用失败”计数——网络超时与业务异常语义不同，必须单独识别
超时后立即执行本地降级，不依赖远程响应
一旦捕获 TimeoutException，应跳过任何重试逻辑（除非明确配置了带退避的有限重试），直接进入降级分支：
- 返回缓存中的旧数据（需校验 freshness，例如 age
- 调用本地静态兜底接口（如返回默认商品列表、空用户信息）
- 异步记录日志并上报监控（如 Prometheus counter + tag: reason=timeout）
- 禁止在降级逻辑中再发起新的远程调用——否则可能形成降级链路超时
结合超时时间分级，实现细粒度熔断策略
单一全局超时值无法适配多级依赖场景。可按服务重要性或 SLA 分级设置超时，并差异化响应：
- 核心服务（如支付）设较短超时（800ms），超时即强熔断 + 告警
- 非核心服务（如推荐）设较长超时（2s），超时后先降级，连续 3 次再开启熔断
- 利用 Feign 的 options 或 Spring Cloud OpenFeign 的 feign.client.config.default.connectTimeout 实现 per-client 配置
注意超时异常的传播边界与包装问题
某些 RPC 框架（如 Dubbo、gRPC）会将原始 TimeoutException 包装成框架异常（如 RpcException、StatusRuntimeException）。若未解包，熔断器将无法识别：
- Dubbo 中需检查 e.getCause() instanceof TimeoutException
- gRPC 中需判断 e.getStatus().getCode() == Status.Code.DEADLINE_EXCEEDED
- 建议统一封装 RPC 调用模板，在 catch 块中做异常归一化处理，暴露标准 TimeoutException 给上层
