为什么不用 Hystrix-Go 直接套用 Java 那套逻辑
Hystrix-Go 是对 Netflix Hystrix 的 Go 移植，但 Go 的并发模型（goroutine + channel）和 Java 的线程池隔离完全不同。直接照搬 command pattern 容易卡死 goroutine 或漏掉超时清理。
-
Hystrix.Go默认不自动回收 goroutine，Do调用后若没显式处理context或超时，可能堆积大量僵尸 goroutine - Java 里靠线程池限流，Go 里得靠
semaphore或rate.Limiter单独控制并发数，Hystrix.Go自带的MaxConcurrentRequests只是计数器，不阻塞也不排队 - 熔断状态变更（如
Open→HalfOpen）是异步轮询的，没有回调钩子，想记录日志或告警得自己包一层
怎么配 hystrix.Go 才不丢请求又不压垮下游
关键不是调高 Timeout 或关掉熔断，而是让失败感知快、恢复试探稳、流量入口可控。
- 必须设
Timeout: 800（单位毫秒），比下游平均 P95 延迟高 20%～30%，太长会拖慢整个调用链 -
MaxConcurrentRequests设为下游服务能扛住的并发上限（比如 100），超过的请求立刻走Fallback，别排队等 -
RequestVolumeThreshold别设太低（如 5），生产环境建议 ≥20，避免偶发抖动就误熔断 - 一定要配
SleepWindow: 30000（30 秒），太短会导致反复开闭，太长会让故障恢复滞后
Do 和 DoC 选哪个？为什么总 panic
Do 是最简调用，但一旦底层函数 panic，Hystrix.Go 不 recover，直接向上抛；DoC 支持传入 context.Context，能统一控制超时和取消，更安全。
- 永远优先用
DoC，哪怕只传context.Background()，它内部做了 panic recover 并转成 error - 如果用
Do，必须确保你传进去的函数绝对不 panic，否则整个调用栈崩掉 -
DoC返回的 error 是*hystrix.Error类型，可判断err.FailureType == hystrix.ErrTimeout或hystrix.ErrRejected做差异化处理
限流要单独做，别指望 Hystrix.Go 拦住所有流量
Hystrix.Go 的熔断不等于限流：它只在失败率超标后拒绝新请求，但突发流量仍会打到 DoC 入口，可能瞬间耗尽 goroutine 或连接数。
立即学习“go语言免费学习笔记（深入）”；
- 在 HTTP handler 层加
golang.org/x/time/rate.Limiter，按 IP 或 token 桶限速，挡在熔断之前 - 数据库/Redis 调用前加信号量（如
golang.org/x/sync/semaphore），限制最大并发连接数，防止打满下游连接池 - 如果用了 gRPC，务必在 client 端配置
WithBlock()和WithTimeout()，否则Hystrix.Go熔断了，底层 conn 还在傻等
真正难的不是配几个参数，而是搞清每个开关背后的真实资源约束——goroutine 数、连接数、下游响应时间分布、错误类型是否可重试。这些不摸清楚，光套模板只会让问题更隐蔽。
