hystrix-go的do方法不触发降级，根本原因是未注册fallback函数或panic未被显式处理；它仅在显式调用fallback时生效，不会自动为任意panic插入降级逻辑。
为什么 Hystrix-go 的 Do 方法不触发降级？
根本原因通常是命令未注册降级函数，或执行时 panic 没被 Hystrix-go 捕获。它只捕获显式调用 fallback 的场景，不会自动为任意 panic 插入降级逻辑。
- 必须在
hystrix.Go或hystrix.NewCommand中传入fallback函数，否则熔断后直接返回错误，不走降级 - 若业务函数内发生 panic，
Hystrix-go会将其转为hystrix.ErrFailedExecution，但不会自动调用 fallback —— 除非你在 fallback 函数里手动处理该错误类型 - 常见误写：
hystrix.Go("cmd", fn, nil)，第二个参数是执行函数，第三个才是 fallback；传nil就等于放弃降级
hystrix.Do 和 hystrix.Go 怎么选？
hystrix.Do 是同步阻塞调用，hystrix.Go 返回 chan 支持异步等待，二者底层都走同一套熔断器逻辑，但行为差异直接影响超时控制和错误传播。
-
hystrix.Do：适合简单 RPC 调用，超时由hystrix.CommandConfig.Timeout控制，失败时直接返回 error，不区分是熔断、超时还是降级结果 -
hystrix.Go：返回chan interface{}和chan error，可配合select做更细粒度的超时/取消控制，但需自行处理 channel 关闭和 goroutine 泄漏风险 - 注意：
hystrix.Go不会自动设置默认超时，必须显式传入含Timeout的hystrix.CommandConfig，否则用全局默认值（默认 1000ms）
熔断器没生效？检查这三处配置
熔断依赖统计窗口、错误率阈值和最小请求数，缺一不可。本地测试常因流量不足或时间窗口太短导致始终处于“closed”状态。
-
RequestVolumeThreshold：默认 20，意味着 10 秒窗口内至少 20 次调用才开始计算错误率；压测 QPS 低时建议调低到 5–10 -
ErrorPercentThreshold：默认 50，即错误率 ≥50% 才熔断；若服务偶发超时，可能需要提高到 70–80 避免误熔 -
SleepWindow：熔断后等待多久尝试半开，默认 60s；开发联调时建议设为 5000（5 秒），否则要等太久才能验证恢复逻辑
降级函数里再调远程服务，会二次熔断吗？
不会。降级函数本身不经过任何 Hystrix 包装，它是普通 Go 函数，所有内部调用都绕过熔断器。这是设计使然，也是最容易被忽略的陷阱。
- 例如：主命令调用下游 HTTP 接口失败，降级函数去查本地缓存 —— 安全；但如果降级函数又发起另一个
hystrix.Do调用，那这个新调用会有独立熔断器，和原命令无关 - 副作用：若降级路径本身不稳定（比如依赖 Redis），整个请求仍可能失败，且错误不会计入原命令的熔断统计
- 建议：降级逻辑尽量轻量，避免网络 I/O；如必须调外部服务，应为其单独配置更宽松的熔断策略（如更高错误阈值、更长 sleep window）
