2026年生产环境必须弃用hystrix-go，因其已归档、原子计数竞争致熔断失效、不支持context.context透传，应立即迁移到sony/gobreaker；hystrix.do会直接panic冒泡导致服务崩溃，须改用hystrix.doc并配合显式context与外部限流。
hystrix-go 已不推荐用于新项目——它缺乏对 goroutine 生命周期的主动管理，且 Do 会直接 panic 向上冒泡，生产环境极易引发服务抖动甚至崩溃。真正可用的方案是用 DoC + 显式 context.Context，并配合外部限流。
为什么 hystrix-go 的 Do 会 panic？
hystrix.Do 内部不做 recover，只要传入的执行函数 panic（比如 http.Get 返回 nil resp 后直接调用 resp.Body.Close()），整个调用栈就崩了，HTTP handler 直接 500。
- 必须改用
hystrix.DoC，哪怕只传context.Background()，它内部做了 panic recover 并转成*hystrix.Error -
hystrix.DoC返回的 error 是具体类型，可安全判断：err.FailureType == hystrix.ErrTimeout或hystrix.ErrRejected - 别依赖
MaxConcurrentRequests挡流量——它只是计数器，不阻塞、不排队，超限请求仍会进到你的函数里，可能瞬间打满 goroutine
Timeout 和 SleepWindow 怎么设才不误伤？
这两个参数不是拍脑袋定的，得贴着下游真实延迟分布来配：
-
Timeout设为下游 P95 延迟 × 1.2～1.3，比如 P95 是 600ms，就设800（单位毫秒）；设太长会让调用链卡死，太短则误判失败 -
SleepWindow生产建议 ≥30000（30 秒），避免抖动导致熔断器反复开闭；低于 10 秒基本等于无效配置 -
RequestVolumeThreshold别设 5 或 10，至少 ≥20，否则偶发网络丢包就触发熔断
降级逻辑本身必须可靠，否则雪崩从这里开始
fallback 函数不是“随便 return 个默认值”就完事——它运行在熔断已打开的状态下，很可能并发很高，且没有额外资源保护：
- 降级返回的数据必须是纯内存值或本地 LRU 缓存，禁止再发起 HTTP/DB 调用
- 如果 fallback 需要读缓存（如 Redis），务必加独立限流（
golang.org/x/time/rate.Limiter）和超时控制 - 记录日志时用异步写或采样（比如每 100 次 fallback 才记一次），避免日志刷爆磁盘或 IO
熔断 ≠ 限流，必须分层防御
hystrix-go 只管失败率，不管流量大小。突发流量会直接冲垮 DoC 入口：
- HTTP 层加
rate.Limiter，按 IP 或 token 桶做第一道限速 - 数据库/Redis 客户端前加
golang.org/x/sync/semaphore，硬控最大连接数 - gRPC client 必须配
grpc.WithTimeout和grpc.WithBlock(false)，否则熔断了底层 conn 还在等 handshake
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
