Beego本身不提供限流、降级、熔断能力，因其是MVC框架而非服务治理框架；所有相关逻辑须手动集成rate.Limiter或gobreaker等第三方库，并在Controller中自行实现拦截、判断与降级响应。
Beego 本身不提供限流、降级、熔断能力
Beego 是 MVC 框架，不是服务治理框架。它没有内置的 rate limiter、circuit breaker 或 fallback 组件。所有“限流”“熔断”逻辑必须手动集成第三方库或自己实现，框架只负责把请求路由到 Controller，剩下的全靠你填。
在 Beego 中接入 golang.org/x/time/rate 做简单限流
这是最轻量、也最容易落地的限流方式，适合单机 QPS 控制（如每个 IP 每秒最多 5 次请求）。关键点不是“能不能加”，而是“加在哪”和“怎么复用”：
- 限流器不能每次请求都新建 —— 必须定义为全局变量或按 key（如 IP）缓存，否则内存暴涨 + 性能归零
- Beego 的
Controller.Run()执行前没有统一钩子，推荐放在BeforeExec()方法里，但要注意：它对静态文件、404 路由也生效，需手动过滤 -
rate.Limiter.Wait()会阻塞 goroutine，高并发下慎用；更推荐TryConsume()+ 返回 429
示例片段：
var ipLimiter = map[string]*rate.Limiter{}
func (c *BaseController) BeforeExec() {
ip := c.Ctx.Input.IP()
if lim, ok := ipLimiter[ip]; ok {
if !lim.TryConsume(1) {
c.Ctx.Output.SetStatus(429)
c.ServeJSON()
return
}
} else {
ipLimiter[ip] = rate.NewLimiter(rate.Every(time.Second), 5)
}
}
用 github.com/sony/gobreaker 实现熔断，但必须自己决定“失败”定义
Beego 不自动标记请求失败 —— 它不会因为你 c.Ctx.Output.SetStatus(500) 就触发熔断。gobreaker 只响应你显式调用的 cb.Execute()，所以你要在业务逻辑中包裹所有可能出错的外部调用（如 HTTP client、DB 查询）：
- 不要在 Controller 方法顶层用 gobreaker —— 那样整个请求生命周期都被包进熔断，连参数解析失败都会算作“失败”
- 每个外部依赖建议配独立
gobreaker.CircuitBreaker实例（比如 userSvcCB、orderSvcCB），避免一个服务挂了拖垮全部 - 注意
cb.Execute()返回的是error，不是 HTTP 状态码；你要自己把 error 映射成c.Ctx.Output.SetStatus()和响应体
典型误用：
// ❌ 错：把整个 Get() 包进去，连 JSON 解析错误都进熔断
err := cb.Execute(func() error { c.Get(); return nil })
// ✅ 对：只包真正可能失败的下游调用
resp, err := cb.Execute(func() (*http.Response, error) {
return http.DefaultClient.Do(req)
})
降级逻辑只能写在 Controller 里，且无法全局声明
Beego 没有类似 Spring Cloud 的 @HystrixCommand(fallbackMethod = "...") 机制。降级必须手写分支判断，而且得提前想好“降级返回什么”：
- HTTP 降级：返回缓存数据、兜底 JSON（如
{"code":200,"data":[]}）、甚至静态 HTML 页面 - 数据库降级：查不到就返回空结构体，或 fallback 到 Redis 缓存（但 Redis 也挂了呢？得再套一层 fallback）
- 别忘了日志 —— 降级不是静默吞错，要用
beego.Error()记录触发原因，否则线上出问题根本没法回溯
容易被忽略的一点：Beego 的 this.Data["json"] 和 this.ServeJSON() 在降级路径里仍要调用，否则响应为空；很多人写了降级逻辑却忘了写输出，结果前端收了个 200 空响应。
