Revel 框架不内置熔断与降级能力，需手动集成 resilience4j-go 等库，通过 circuitbreaker.Execute 包裹调用并显式编写 fallback 函数，且须合理配置滑动窗口与最小调用数以保障半开状态准确判定。
Revel 框架本身不内置熔断与降级能力，必须手动集成第三方库（如 resilience4j 或 go-breaker）并结合中间件/拦截器实现。 它不像 Spring Cloud 那样有 @HystrixCommand 这类开箱即用的注解支持，所有逻辑需开发者显式控制。
为什么 Revel 没有原生熔断支持
Revel 是一个轻量、无侵入的 Go Web 框架，设计哲学是“提供骨架而非胶水”。它不强制依赖任何容错组件，也不维护服务调用链路状态（比如失败计数、滑动窗口统计），因此无法自动触发熔断。所有熔断决策必须由你决定何时调用、如何包装、怎么 fallback。
-
revel.Interceptor可拦截请求，但不感知下游 HTTP 调用结果 - 框架不封装 HTTP client，
http.Client的超时、重试、错误分类全由你负责 - 没有类似 Hystrix 的线程池隔离或信号量模式，资源争用需自行管控
用 resilience4j-go 实现熔断器
resilience4j-go 是目前最接近 Hystrix 语义的 Go 熔断库，支持 Closed/Open/Half-Open 状态机和失败率/响应时间阈值配置。关键不是“加个装饰器”，而是把外部调用包裹进 circuitbreaker.Execute。
- 定义全局熔断器实例：
cb := circuitbreaker.NewConcurrentCircuitBreaker(circuitbreaker.WithFailureRateThreshold(50)) - 在 service 层调用下游 API 时，必须用
cb.Execute包裹真实请求逻辑，例如：resp, err := cb.Execute(func() (interface{}, error) { return http.DefaultClient.Do(req) }) - 若返回
circuitbreaker.ErrRejected，说明处于Open状态，此时应直接走降级逻辑，不能重试 - 注意：返回值需是
interface{}，实际使用中要类型断言或封装统一响应结构
服务降级必须显式编写 fallback 函数
Revel 中没有 fallbackMethod 这样的反射机制，降级逻辑必须写成普通函数，并在熔断器执行失败后手动调用。它不是“自动兜底”，而是“条件分支”。
- 不要在
Execute的闭包里写降级，那会绕过熔断判断；降级必须放在err != nil分支中 - 示例结构：
result, err := cb.Execute(func() (interface{}, error) { return callDownstreamAPI() }) if err != nil { if errors.Is(err, circuitbreaker.ErrRejected) { return fallbackGetProduct(), nil // 显式调用降级函数 } return nil, err // 其他错误仍向上抛 } return result.(string), nil - 降级函数可返回缓存数据、静态默认值，或调用另一个低优先级服务（如本地 Redis 查询）
- 避免在 fallback 中再触发一次可能失败的远程调用，否则会形成嵌套雪崩
容易被忽略的半开状态处理细节
熔断器进入 Half-Open 后，只允许有限请求数通过，但 Revel 的 HTTP handler 是并发执行的，你无法靠单个请求判断是否“成功恢复”。必须依赖 resilience4j-go 内置的滑动窗口统计（如 WithSlidingWindow），且窗口大小要匹配你的 QPS 基线。
- 默认滑动窗口是 100 个事件，若你每秒只有 5 个请求，窗口要积累 20 秒才更新状态 —— 这会导致恢复延迟过长
- 建议设为时间窗口（
WithSlidingWindowByTime），例如 60 秒内统计最近失败率 - 务必设置
WithMinimumNumberOfCalls(10)，防止低流量下误判（比如 1 次失败就跳到 Open） - 日志中要记录
circuitbreaker.StateChangedEvent，否则很难排查为何突然熔断
