应避免使用hystrix-go，因其将Java线程池模型硬套Go导致竞争和误判；生产推荐gobreaker+rate.Limiter组合，限流需正确配置limit与burst、置于入口层，响应体限速须用juju/ratelimit，熔断与限流须按“先限流、后熔断”顺序协同。
为什么不用 hystrix-go 做熔断限流
它不是为 Go 设计的，硬套会出问题。hystrix-go 把 Java 的线程池隔离、命令包装那一套搬过来，在 goroutine 场景下反而制造竞争和误判：MaxConcurrentRequests容易和 HTTP server 的连接池参数冲突，导致请求卡在“排队等执行”而非真实失败；SleepWindow是固定时间，不感知下游是否真恢复；默认为每个命令起 goroutine 池，完全违背 Go 的轻量并发模型。
真正稳定生产用的是 gobreaker + rate.Limiter 组合——前者单文件、状态清晰、无依赖；后者是标准库，线程安全、高并发验证过。别被名字误导，hystrix-go 已基本被社区弃用。
rate.Limiter 该怎么配才不翻车
rate.Limiter 的 limit 参数单位是「每秒令牌数」，不是字节也不是每分钟。写成 rate.Every(time.Second/10) 或 rate.Limit(10) 都表示 10 QPS；burst 必须 ≥ limit，否则初始化直接 panic——它代表桶容量，也决定突发容忍能力（比如 limit=5, burst=20 允许短时 20 次请求）。
- 别设
burst过大（如 1000），瞬时流量照样打穿后端 - 别在 handler 里对每个请求调
limiter.Wait(ctx)再进业务逻辑：后端慢时令牌长期被占，实际吞吐远低于配置值 - 限流必须放在入口层（网关或中间件），且只对明确外部路径生效（如
/api/v1/payment），健康检查、metrics 接口绕过 - 多个路由或用户要差异化限速？用
sync.Map存"ip:192.168.1.100"→*rate.Limiter映射，但记得加 TTL 清理闲置实例（比如 10 分钟无请求就删）
服务端响应体限速为什么不能用 rate.Limiter
因为 rate.Limiter 的 WaitN(ctx, n) 里的 n 是「次数」，不是字节。你设 rate.NewLimiter(rate.Limit(1024*1024), 1024*1024)，意思是“每秒最多 1MB 次调用”，不是“每秒最多 1MB 字节”——结果可能是每秒发 1MB 个 1 字节包，速率失控。
立即学习“go语言免费学习笔记（深入）”；
真正该用的是 github.com/juju/ratelimit：ratelimit.NewBucketWithRate(1024*1024, 1024*1024) 第一个参数就是字节/秒，语义精准。使用时注意：
- 必须先调
w.WriteHeader(statusCode)，再包装ResponseWriter，否则状态码可能被覆盖 - gzip 中间件会绕过你的限速，得包装压缩后的
ResponseWriter，而不是原始的 - 务必显式设置
Content-Length，避免Transfer-Encoding: chunked导致限速不可控 - 限速后单次
Write耗时变长，超时要配够，否则 client 断连、server goroutine 泄漏
熔断器和限流器怎么协同才不互相干扰
它们不是并列开关，而是有严格顺序和状态反馈的配合关系：必须先限流、再熔断。如果反过来，大量请求在限流队列里排队超时，会被熔断器误判为失败率飙升，提前打开熔断。
正确协作方式：
- 熔断器打开时，应主动绕过限流检查：
if cb.State() == gobreaker.StateOpen { return errors.New("service unavailable") }，避免请求在限流队列空等 - 限流器和熔断器要分层部署：限流放最外层（网关/入口中间件），熔断放业务调用层（如调下游 HTTP 服务前）
- 分布式场景下，全局限流和熔断状态必须同步：用 Redis + Lua 脚本保证原子性，别靠本地内存
复杂点在于状态联动——限流器没做错，熔断器也没做错，但两者没对齐节奏，就会放大故障。这没法靠堆库解决，得从设计上把“谁拦洪峰、谁防雪崩”的职责划清楚。
