fiber 不内置熔断与降级能力，因其定位为轻量路由层，需集成 gobreaker 等第三方库；应按下游服务维度初始化熔断器，封装 execute 以透传 context，并在 stateopen 时返回降级响应。
Fiber 本身不提供熔断与降级能力，必须自行集成第三方库或手写逻辑 —— 这是所有误踩坑者的共同起点。
为什么 Fiber 没有内置熔断器
Fiber 的设计定位是轻量 HTTP 路由层，它连中间件生命周期都只暴露 Next() 和 SendStatus() 等基础方法，更不包含服务治理语义。所谓“Fiber 微服务”，实际是开发者在 fiber.Ctx 上挂载自定义字段（如 c.Locals("circuit_breaker")），再配合外部状态管理实现的伪熔断。
- 官方 middleware 列表中没有
circuit-breaker、fallback或rate-limit等治理类中间件 - 其
fiber.Config不支持注册全局熔断策略，也没有类似 Spring Cloud 的@HystrixCommand注解机制 - 所有错误恢复逻辑（如 fallback handler）需手动在每个路由 handler 内判断
err != nil后分支处理
用 gobreaker 实现可落地的熔断中间件
Go 生态最常用的是 sony/gobreaker，它轻量（单文件）、无依赖、支持状态持久化。但直接套用会出问题：它的 Execute 方法默认同步阻塞，而 Fiber 的 handler 是并发执行的，需注意上下文取消和超时传递。
- 不要在中间件里直接调用
cb.Execute()，应封装为函数接收context.Context并透传c.Context() - 熔断器实例建议按下游服务维度初始化（如
userSvcCB、paymentSvcCB），避免共用状态导致误熔断 - 触发熔断后，
gobreaker.State变为StateOpen，此时应返回预设降级响应，而非继续调用下游 - 示例关键片段：
func CircuitBreaker(cb *gobreaker.CircuitBreaker) fiber.Handler { return func(c *fiber.Ctx) error { err := cb.Execute(func() (interface{}, error) { select { case
降级响应不能只靠 return c.JSON()
真实微服务场景中，降级往往需要读缓存、查本地兜底数据、甚至调用另一个低优先级服务。Fiber 的 handler 执行流是线性的，一旦 c.Send() 或 c.JSON() 被调用，后续代码不会执行 —— 但很多人忘了检查是否已发送响应。
- 务必在降级逻辑前加
if !c.Response().Committed { ... }判断，否则可能 panic：“response already committed” - 避免在降级路径中调用
c.Next()，这会导致重复路由匹配，引发无限递归或 panic - 若需异步加载降级数据（如从 Redis 获取），必须用
go func() { ... }()启动协程，并确保不操作已结束的c.Context() - 推荐把降级逻辑抽成独立函数，签名形如
func(c *fiber.Ctx) error，便于单元测试和复用
熔断指标采集与告警必须外挂
Fiber 不暴露请求耗时分布、失败率、当前熔断状态等指标，这些全得靠你自己埋点。别指望 fiber.New() 配个参数就能导出 Prometheus metrics。
- 用
prometheus.NewCounterVec定义fiber_circuit_breaker_state{service="user",state="open"}类型指标 - 在
gobreaker.OnStateChange回调里更新指标，注意 goroutine 安全（用prometheus.MustRegister()注册一次即可） - 熔断器切换到
StateHalfOpen时，建议记录日志并触发钉钉/企微告警 —— 这是故障恢复的关键信号点 - 特别注意：gobreaker 默认的
ReadyToTrip函数基于失败请求数，但在高 QPS 场景下容易误判，建议改用失败率 + 时间窗口组合判断
真正难的不是写几行熔断代码，而是让每个服务实例的熔断状态在集群中保持一致 —— Fiber 不提供跨节点状态同步，你得自己对接 Consul KV、Redis Pub/Sub 或 etcd watch。这点常被忽略，直到压测时发现部分节点还在狂刷失败请求。
