核心问题是超时请求不释放资源，导致线程池耗尽与雪崩；必须将超时控制前置到调用方，并与熔断联动统计超时失败，配合限流、降级、隔离实现链路级协同防护。
微服务依赖超时引发的故障，核心问题不是“慢”，而是“不释放资源”。一个超时请求若未及时中断，会持续占用线程、连接、内存，导致上游服务线程池耗尽、下游堆积加剧，最终雪崩。实现快速熔断的关键，是把“超时控制”和“熔断决策”两层机制联动起来，而不是只配个 timeout 就完事。
超时必须前置到调用发起点
不能依赖下游服务自己响应超时。比如订单服务调用库存服务，必须在订单服务侧就设置明确的上下文超时（如 800ms），而非指望库存服务返回一个 504。Go 中用 context.WithTimeout，Java 中用 Hystrix 的 execution.isolation.thread.timeoutInMilliseconds 或 Feign 的 readTimeout。
- 超时值要略大于下游 P99 响应时间，但远小于你整体接口 SLA（例如 SLA 是 2s，下游 P99 是 300ms，可设为 600–800ms）
- 避免“懒加载首次超时”：Spring Cloud 默认首次 Feign 调用较慢，建议预热或单独配置首次超时放宽
- HTTP 客户端、gRPC Client、DB 连接池都要独立设超时，不能只靠框架级熔断兜底
熔断器必须基于超时失败做统计
很多团队误把“业务异常”和“超时失败”混为一谈。超时是典型的硬性失败（no response），应立即计入熔断错误计数；而部分业务异常（如参数校验失败）不应触发熔断。Hystrix 和 gobreaker 都支持区分异常类型：
- Hystrix 中通过 ignoreExceptions 排除不参与熔断的异常类（如 IllegalArgumentException）
- gobreaker 的 ReadyToTrip 函数可定制逻辑，只对 context.DeadlineExceeded 或 net.ErrClosed 等超时/连接类错误计数
- 建议初始熔断阈值设为连续 3 次超时失败（非总错误率），响应更快
半开状态要带超时探测，避免试探压垮下游
熔断器进入半开后，若直接放行全量请求试探，可能瞬间打爆刚恢复的下游。正确做法是：在半开期间，仅允许极少量、带严格超时的探测请求，并限制并发数。
- Hystrix 的 MaxConcurrentRequests（半开时最大请求数）建议设为 1–3
- gobreaker 的 MaxRequests 参数就是为此设计，配合 Timeout 使用
- 探测成功后，需连续 N 次（如 2–3 次）成功才真正关闭熔断器，避免抖动误判
链路级协同：超时 + 熔断 + 限流缺一不可
单靠熔断解决不了超时传导。比如库存服务已超时，但订单服务仍持续重试，反而加重压力。必须叠加：
- 限流：在网关或 Feign 客户端层对库存接口 QPS 限流（如 Sentinel 集群模式限流 500 QPS），防止突发流量冲击
- 降级：超时熔断触发后，立即返回缓存库存、默认值或空结果，不走 fallback 二次调用
- 隔离：为库存调用分配独立线程池或信号量（Hystrix 的 threadPoolKey），避免拖垮其他依赖
