hystrix.Go易panic因不捕获内部panic，需手动recover；其fallback无法获取原始参数；配置中仅Timeout、MaxConcurrentRequests等少数项生效；旧版库在Go1.21+有统计竞争风险，建议迁移到gobreaker或resilience-go。
为什么直接用 hystrix.Go 容易 panic？
因为 hystrix.Go 默认不处理函数内部 panic，一旦被包裹的函数 panic，它会原样抛出，上层没 recover 就直接崩。这不是库的 bug，而是设计使然——它只管超时、熔断、统计，不管错误类型兜底。
- 必须自己在业务函数里
defer func() { recover() }()，或者在外层加 wrapper - 别依赖
hystrix.Go自动吞异常；它的run参数是func() error，不是func() - 常见误写：
hystrix.Go("cmd", func() { ... }, fallback)→ 编译不过，因为签名不匹配
hystrix.SetCommandConfig 配置项哪些真有用？
很多参数看着重要，实际项目里只有几个影响行为。比如 Timeout 和 MaxConcurrentRequests 会立刻改变调用表现，但 RequestVolumeThreshold 和 SleepWindow 不设对，熔断根本不会触发。
-
Timeout：单位毫秒，超时后走 fallback，但注意：它只中断 goroutine，不终止后台真实调用（比如 HTTP 请求还在发） -
RequestVolumeThreshold：默认 20，意思是 10 秒内至少 20 次失败才可能熔断；流量低的服务得调小，否则永远不熔 -
SleepWindow：默认 60 秒，熔断后这个时间里所有请求直走 fallback；太长会导致恢复慢，太短会让下游反复被冲击 -
ErrorPercentThreshold：默认 50，但它是「最近 10 秒内失败率」，不是全局统计
fallback 函数里能访问原始参数吗？
不能。hystrix.Go 的 fallback 签名是 func() error，和主函数一样，是独立执行的闭包。它拿不到主函数的入参，也没法知道这次失败是因为超时还是熔断。
- 如果需要区分原因，得自己在主函数里记录上下文，比如用
context.WithValue传标识，再在 fallback 里读（但 fallback 不一定和主函数共享 context） - 更靠谱的做法：fallback 只做「安全兜底」，比如返回缓存值、空结构体或默认错误，别试图重试或查 DB
- 别在 fallback 里调另一个
hystrix.Go，容易嵌套熔断、逻辑失控
Go 1.21+ 用 hystrix-go 还安全吗？
能跑，但底层依赖的 sync/atomic 操作在新版 runtime 下有隐含竞争风险——库用 int64 做计数器，但没加 memory barrier，高并发下统计可能不准，导致熔断阈值漂移。
立即学习“go语言免费学习笔记（深入）”；
- 官方已归档，最后更新是 2020 年，没人修 race，也不支持
context.Context透传 - 生产环境建议换
sony/gobreaker或resilience-go，它们用标准库sync/atomic更严谨，也支持自定义状态回调 - 如果硬要留着，至少把
hystrix.ResetAll加到测试 teardown 里，避免测试间状态污染
