hystrix.go会卡住http handler是因为默认无超时，需显式配置timeout并用select等待结果或超时。
为什么 hystrix.Go 会卡住 HTTP handler 而不返回？
因为 hystrix.Go 默认不带超时控制，一旦后端依赖卡死或响应极慢，它会一直等下去，把整个 HTTP goroutine 拖住。Web 服务里每个请求都跑在独立 goroutine 上，这种“无限等待”直接导致连接堆积、线程耗尽。
- 必须显式传入
timeout参数，比如hystrix.Go("user-service", fn, &hystrix.CommandConfig{Timeout: 800}) - HTTP handler 内部调用
hystrix.Go后，不能直接 return，得用select等待结果或超时：result := make(chan error, 1)<br>hystrix.Go("user-service", func() error { /* ... */ }, &hystrix.CommandConfig{Timeout: 800})<br>select {<br>case err := <-result:<br> if err != nil { /* 处理错误 */ }<br>case <-time.After(900 * time.Millisecond):<br> /* 主动降级 */<br>} - 别把
hystrix.Go和http.DefaultClient.Do混着用——前者不接管底层 TCP 连接超时，后者才管；两个超时要错开（比如 hystrix timeout 设为 800ms，HTTP client timeout 设为 750ms），否则 hystrix 可能永远等不到 client 返回
fallback 函数里 panic 会导致熔断器失效吗？
会。hystrix-go 的 fallback 是同步执行的，如果 fallback 本身 panic，整个 hystrix.Go 调用就 panic 了，既没走成功路径也没走熔断逻辑，更不会更新失败计数器，等于绕过了所有保护机制。
- fallback 函数内部必须做 recover：
func() error {<br> defer func() {<br> if r := recover(); r != nil {<br> log.Printf("fallback panicked: %v", r)<br> }<br> }()<br> return someSafeFallback()<br>} - fallback 不该再调外部服务——它本就是兜底，再加一层依赖就失去意义
- 如果 fallback 需要读缓存，优先用本地内存（如
sync.Map），避免引入 Redis 或 DB 调用
并发量上来后 hystrix.NewStream 报 “too many open files”
这不是 hystrix-go 的 bug，是它默认用 net/http 做 metrics 推送时，每秒新建大量短连接，没复用连接池，系统文件描述符被快速耗尽。
- 禁用自动 metrics 上报：启动时调用
hystrix.ConfigureCommand("cmd-name", hystrix.CommandConfig{DisableInstrumentation: true}) - 如果真需要监控，改用拉取模式——在 Prometheus 中配置
/metricsendpoint，由服务暴露指标，而不是 hystrix 主动推 - 检查
http.DefaultTransport的MaxIdleConnsPerHost，至少设为 100；hystrix 自己不管理 transport，但它的 metrics client 会偷偷用 default transport
熔断器打开后，新请求进来的 fallback 执行时机不对
熔断器状态是异步更新的，但 hystrix.Go 在判断是否走 fallback 时，只看当前快照。如果刚好在熔断打开瞬间有请求进来，它可能仍尝试执行主函数，而不是立刻 fallback——这会让少量请求撞上已知不可用的下游。
立即学习“go语言免费学习笔记（深入）”；
- 加一层前置检查：
if hystrix.GetCircuit("user-service").IsOpen() {<br> return fallback()<br>}注意这个判断是轻量的，不触发任何网络或锁竞争 - 确保
RequestVolumeThreshold和ErrorPercentThreshold设置合理：太低会导致误熔断，太高又起不到保护作用；建议从20和50开始试，再根据实际错误率调整 - 别依赖
hystrix.SetLogger来观察熔断开关——日志是异步刷的，看到日志时状态可能已经变了
事情说清了就结束。真正难的不是配几个参数，而是搞清楚哪些环节是同步阻塞、哪些是异步更新、哪些错误会被吞掉——这些地方一错，限流和熔断就变成幻觉。
