生产环境应弃用hystrix-go，因其照搬java线程池模型与go goroutine冲突，易误判失败、卡死请求；稳定组合是gobreaker+rate.limiter，需分层部署、先限流后熔断、状态联动，避免互相干扰。
生产环境别用 hystrix-go，它和 Go 的 goroutine 模型天然冲突，容易误判失败、卡死请求；稳定组合是 gobreaker + rate.Limiter，但必须分层部署、状态联动，否则限流和熔断会互相干扰。
为什么 hystrix-go 在 Go 里容易出问题
它照搬 Java Hystrix 的线程池隔离模型，在 Go 里反而引入冗余开销：
-
MaxConcurrentRequests配置常和 HTTP server 的连接池或MaxHeaderBytes冲突，导致请求卡在“等待执行”而非真实失败 - 默认为每个命令维护独立 goroutine 池，而 Go 本就不需要线程级隔离——错误该由
context和超时控制 -
SleepWindow是固定时间，不感知下游是否真恢复；gobreaker的Interval+Timeout组合更符合状态机语义 - 社区已基本转向
gobreaker或resilience-go：前者单文件、无依赖、状态清晰，后者支持context取消和指标导出
rate.Limiter 配置错一个参数就等于没限
rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示「每 100ms 放一个 token，最多借 5 个」，即平均 10 QPS、突发容忍 5 请求——burst 过大（比如设成 100）会让瞬时流量打穿后端：
- 别在 handler 里对每个请求调
limiter.Wait(ctx)后再进业务逻辑：若后端慢，令牌被长期占用，实际吞吐会远低于配置值 - 正确姿势是把限流放在入口网关或中间件层，且只对明确的外部调用路径生效（如
/api/v1/payment），不对内部health check或metrics接口限 - 它本身是并发安全的，不需要额外加锁；但若多个 handler 共享同一个
limiter实例，需确认其粒度是否合理（比如按用户 ID 分 key，就不能全局共用一个）
熔断器和限流器怎么协同才不打架
二者不是并列开关，而是有先后顺序和状态反馈的配合关系：
- 必须先限流、再熔断：限流拦住洪峰，熔断防雪崩。如果反过来，熔断器可能因大量排队请求超时而误判失败率
- 熔断器打开时，应主动绕过限流检查：
if cb.State() == gobreaker.StateOpen { return errors.New("service unavailable") }，避免请求在限流队列里空等 -
gobreaker.Settings.RequestVolumeThreshold建议设为略高于限流阈值（如限流 100 QPS，则设为 120），避免低流量下误熔断 - 在限流逻辑中检查熔断器状态，而不是等
cb.Execute抛错后再处理——响应延迟和资源浪费已经发生
真正难的不是写两行 gobreaker.NewCircuitBreaker 或 rate.NewLimiter，而是厘清「谁在什么位置做决策」「失败信号从哪来」「状态变更如何影响下游行为」——这些细节不串联起来，熔断和限流只会各自为政，甚至互拖后腿。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
