单靠context.WithTimeout无法防止雪崩，必须协同熔断、限流、超时、重试四机制：超时需配合http.Client.Timeout和数据库context；熔断用sony/gobreaker并按服务隔离；限流应控连接数而非QPS；重试须带jitter且仅针对可重试错误。
只加 context.WithTimeout 根本防不住雪崩——goroutine 会持续堆积，HTTP 底层连接可能 hang 住几分钟，数据库查询照样忽略超时。真正起作用的是熔断、限流、超时、重试四者协同，缺一不可。
为什么单靠超时控制不了雪崩
超时只是“单次调用”的刹车，不是“系统级节流”：
-
context.WithTimeout只能取消当前 goroutine 的等待，无法中断已发出但未返回的 HTTP 请求或 gRPC 流（底层 TCP 连接仍存活） -
http.Client必须显式设置Timeout字段（优先级高于 context），否则默认无超时，TCP 可能卡住 30 秒以上 - gRPC 客户端必须传入带 deadline 的
context，且服务端需用grpc.UnaryInterceptor提前校验ctx.Deadline()，否则 server 端不感知 - 数据库操作（如
sqlx.QueryContext）必须传入 context，否则db.Query会完全忽略超时
熔断器选型与配置陷阱
别用已停更的 hystrix-go；sony/gobreaker 是当前事实标准，但默认配置极易误判：
- 默认
ReadyToTrip条件是counts.ConsecutiveFailures > 5，对瞬时抖动太敏感；生产建议设为> 30 -
Timeout（半开等待时间）默认 60 秒，建议调至30s左右，避免恢复过慢 - 必须实现
OnStateChange回调，把状态推到 Prometheus 或日志，否则熔断发生时你根本不知道 - 不要共用一个熔断器实例；按下游服务隔离，比如
userSvcBreaker和paymentSvcBreaker必须分开
限流在 K8s 环境下容易失效
golang.org/x/time/rate.Limiter 只管单机 QPS，Pod 扩容后每实例都从零开始计数，整体流量完全失控：
立即学习“go语言免费学习笔记（深入）”；
- 90% 的雪崩来自突发流量打穿数据库连接池或下游 CPU，而 rate.Limiter 对这种场景无效
- 真正要控的是连接数、线程数、队列深度——比如限制
sql.DB.SetMaxOpenConns(20)，而非每秒请求数 - HTTP 层限流建议放在网关（如 Envoy 或 Nginx），用
limit_req控制并发连接数或令牌桶速率 - 若必须在 Go 代码里做，可用
semaphore控制并发调用数（如最多 5 个同时调下游），比 rate 更贴近资源瓶颈
重试必须带 jitter 且仅针对可重试错误
无脑重试会让问题恶化，尤其在雪崩初期：
- 只对网络错误、5xx 响应重试；4xx（如
400 Bad Request、404 Not Found）绝对不重试 - 必须加入随机抖动（jitter），避免大量请求在同一时刻重试——用
github.com/cenkalti/backoff简化实现 - 重试次数建议 ≤ 2 次，配合指数退避（如 100ms → 300ms），再失败就交给熔断器处理
- 注意幂等性：POST 接口重试前必须确保有唯一 token 或数据库唯一索引，否则会写入重复数据
最常被忽略的点是：超时、熔断、限流、重试这四个机制必须在同一个调用路径上串联生效。比如 HTTP 客户端封装里既要传 context，又要套熔断器，还要走限流器，最后才发请求——少任何一个环节，雪崩风险就还在。
