fiber 框架不内置熔断降级，需手动集成 sentinel 等中间件；因 go 版 sentinel 客户端与 java 版 dashboard 兼容性差、文档少、默认不开启响应统计，易导致规则不生效；推荐用 gobreaker、超时重试、本地缓存等轻量方案替代。
Fiber 框架本身不内置熔断降级能力，必须靠中间件手动集成 Sentinel、Hystrix 或自研逻辑；直接用 fiber.New() 启动服务时，所有接口默认“裸奔”，故障会立刻穿透到下游。
为什么 Fiber 的中间件不适合直接套用 Spring Cloud Alibaba Sentinel
Fiber 是 Go 语言的轻量 HTTP 框架，而 Sentinel 是 Java 生态主导的组件，其 Dashboard、规则推送、实时指标采集都依赖 JVM 和 Spring Boot 环境。你在 Fiber 项目里 go get github.com/alibaba/sentinel-golang 能拿到的是 Go 版 Sentinel 客户端，但它和 Java 版 Sentinel Dashboard 不完全兼容（比如规则格式、指标上报协议、控制台 UI 展示逻辑），且社区活跃度低、文档稀疏。
常见错误现象包括：
- 在 Dashboard 配置了熔断规则，但 Fiber 服务压根不触发，
sentinel.Entry返回nil或 panic - 调用
sentinel.LoadRules()后无报错，但簇点链路里看不到资源名，监控面板始终为空 - 慢调用比例阈值设为 60%，实际响应时间全超 2s，却从不熔断——根本原因是 Go 客户端默认未开启响应时间统计（需显式调用
sentinel.InitStat()）
用 sentinel-golang 实现 Fiber 接口熔断的最小可行路径
核心是把每个 HTTP handler 包装成一个 Sentinel 资源，并在中间件中统一做 entry 获取与退出。注意：资源名建议用 HTTP_METHOD:PATH 格式（如 GET:/api/user/:id），避免用动态参数值，否则规则无法匹配。
实操要点：
- 初始化阶段必须调用
sentinel.InitCoreWithConfig()，且配置项flow.RuleCheckInterval建议设为1000（毫秒），否则规则更新延迟高 - 中间件中调用
sentinel.Entry时，要传入sentinel.WithResourceType(sentinel.ResTypeWeb)，否则系统规则（如 CPU 过载保护）不生效 - 熔断后不能简单
return c.Status(503).SendString("service unavailable")，必须调用entry.Exit()，否则并发计数泄漏，后续请求永远被 block - 降级逻辑建议抽成函数，例如
fallbackForUserDetail(c *fiber.Ctx) error，便于单元测试和复用
示例中间件片段：
func SentinelMiddleware() fiber.Handler {
return func(c *fiber.Ctx) error {
resName := fmt.Sprintf("%s:%s", c.Method(), c.Path())
entry, err := sentinel.Entry(
resName,
sentinel.WithResourceType(sentinel.ResTypeWeb),
)
if err != nil {
// 触发熔断或限流，走降级
return fallbackForUserDetail(c)
}
defer entry.Exit()
return c.Next()
}
}
Fiber 中更现实的熔断降级替代方案
对多数中小团队，硬啃 sentinel-golang 成本高、坑多。更推荐组合使用以下轻量手段：
- 用
gobreaker库实现纯内存熔断器：它只关注失败率/超时，不依赖外部控制台，github.com/sony/gobreaker初始化简单，一行代码就能包装任意 HTTP client 调用 - 对下游依赖（如 Redis、MySQL、第三方 API），在
fiber.Client或http.Client层加超时 + 重试 + 熔断，而不是在 HTTP handler 入口层做——前者更贴近故障源头 - 用
fiber.Timeout中间件兜底：设置全局 800ms 超时，比等熔断器判断更快，也避免 goroutine 泄漏 - 降级数据尽量走本地缓存（如
fastcache）或静态 fallback JSON 文件，别再查一次 DB 或调另一个微服务
真正容易被忽略的是：Fiber 的 c.Context().Deadline() 在熔断后不会自动取消 downstream context，如果你在 handler 里启了 goroutine 去异步调下游，必须手动监听 entry.Blocking() 或用 context.WithTimeout 二次封装。
