Beego 不提供开箱即用的限流、降级、熔断能力，需手动集成；HTTP 中间件无法覆盖 ORM、RPC、IO 等非 HTTP 路径，必须在关键调用点（如 DB 查询、HTTP 请求）显式嵌入限流器（如 go-zero governor）、熔断器（如 gobreaker）和分层降级逻辑。
Beego 本身不提供开箱即用的限流、降级、熔断能力，所有这些必须手动集成或自行实现；硬套框架内置中间件会漏掉关键路径，比如 ORM 查询、RPC 调用、文件 IO 等非 HTTP 层环节。
Beego 中间件只能覆盖 HTTP 请求生命周期
限流逻辑放在 BeforeExec 或自定义中间件里，确实能拦住部分非法请求，但存在明显盲区：
-
BeforeExec只在路由匹配后、控制器方法执行前触发，若控制器内调用了一个高耗时的orm.Read()或http.Post()，中间件对此无感知 - 多个控制器共用同一 DB 连接池或 Redis 客户端时，单个请求限流无法防止资源争抢（比如 100 个并发查同一条慢 SQL）
- 熔断器需监控下游服务失败率，而 Beego 的
Context不暴露远程调用链路，你得自己 wrap 所有http.Client或 RPC client
换句话说：HTTP 层限流 ≠ 服务级限流。别把 beego.InsertFilter("/api/*", beego.BeeApp.FilterFunc, limitHandler) 当成银弹。
用 go-zero 的 governor 替代手写限流逻辑
直接复用成熟组件比自己实现漏桶/令牌桶更可靠，尤其在生产环境。go-zero 提供的 governor 包支持：
- 基于 goroutine 数或 QPS 的实时限流（
governor.NewQpsLimiter(100)） - 与 context.Context 集成，超限时返回
errors.Is(err, governor.ErrLimitExceeded) - 可嵌入任意代码段，不限于 HTTP handler，比如 ORM 查询前加一道闸：
if err := limiter.Take(ctx); err != nil { c.Data["json"] = map[string]string{"error": "too many requests"} c.ServeJSON() return } o := orm.NewOrm() o.QueryTable("user").Filter("status", 1).All(&users)
注意：不要在 init() 里全局 new 一个 limiter —— 它不是线程安全的，每个业务路径应配独立实例，或用 sync.Map 按 key（如 "user:query"）缓存。
熔断必须侵入下游调用点，不能只靠中间件
Beego 没有类似 Sentinel 的自动埋点能力，所有外部依赖调用都得显式包裹。典型错误是只给 HTTP handler 加熔断，却忘了：
- ORM 的
Insert()/Read()方法底层走的是数据库连接，失败要计入熔断统计 - 调用其他微服务的
http.DefaultClient.Do()必须替换为带熔断包装的 client - Redis 的
Get()、Set()同样需要 hook，否则缓存雪崩时熔断器永远收不到信号
推荐方式：用 github.com/sony/gobreaker 封装关键调用，例如
var cb *gobreaker.CircuitBreaker
func init() {
cb = gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service-call",
Timeout: 30 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 5
},
})
}
func callUserService() (string, error) {
return cb.Execute(func() (interface{}, error) {
resp, err := http.DefaultClient.Get("http://user-svc/api/profile")
if err != nil {
return "", err
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
return string(body), nil
})
}这个 callUserService() 才是真正可熔断的单元。
降级策略要分层设计，不能只 fallback 到静态 JSON
常见误区是写个 c.Data["json"] = map[string]string{"msg": "service unavailable"} 就算降级了。真实场景中降级必须考虑数据一致性：
- 读操作降级可走本地缓存（如
sync.Map存最近 100 条用户信息），而非直接返回空 - 写操作降级要考虑补偿机制，比如发 MQ 异步重试，或写入本地日志文件待恢复
- Beego 的
Cache模块默认是内存型，重启即丢，生产务必换成redis或memcache驱动
最关键的细节：降级响应的 HTTP 状态码不能全写 200 —— 前端或网关可能依据 5xx 自动重试，而降级结果本就不该被重试。该返回 429、408 或 503 时，就得明确设 c.Ctx.Output.SetStatus(503)。
