beego限流必须在beforeexec过滤器中安全接入，避免误熔断：用全局复用的rate.limiter、禁用new、用ctx.abort("429")而非http.error。
Beego 本身不提供开箱即用的限流与降级能力，所有相关逻辑必须手动集成；直接在中间件里调 rate.Limiter.Allow() 或硬塞 gobreaker 到控制器里，90% 的项目会在线上出现误熔断、漏限流或降级雪崩。
Beego 中间件里怎么安全接入 rate.Limiter
Beego 的 BeforeExec 过滤器是挂载限流逻辑的唯一合理位置，但必须避开三个典型错误：
-
rate.NewLimiter(10, 1)的第二个参数是“突发容量”，不是缓冲队列——超限请求立刻返回false，不会排队；若想排队，必须用Wait(ctx)并配context.WithTimeout - 每个请求都
new rate.Limiter是错的：rate.Limiter不是线程安全的，应按路径或用户维度全局复用（比如用sync.Map缓存不同:id对应的 limiter） - 别在过滤器里直接
http.Error返回 429：Beego 的ctx.ResponseWriter此时可能已被部分写入，应改用ctx.Abort("429")中断流程并清空响应缓冲
示例片段（注册到 filter/filter.go）：
func RateLimitFilter() {
limiter := rate.NewLimiter(rate.Every(time.Second), 10) // 全局共享
web.InsertFilter("/api/*", web.BeforeExec, func(ctx *context.Context) {
select {
case
<h3>为什么不能把 gobreaker 熔断器直接塞进 Controller 方法</h3>
<p>Controller 实例每次请求都会新建，而 <code>gobreaker.CircuitBreaker</code> 必须长期存活才能积累统计窗口数据；在方法内 new 一个熔断器，等于每次请求都重置状态，完全失去熔断意义。</p>
- 正确做法：在
main.go初始化阶段创建熔断器实例，并通过依赖注入或包级变量传递给具体业务方法 - 必须按下游接口粒度隔离：订单查询、用户信息、库存扣减各用独立熔断器，命名如
"order-service:query"，避免共用导致级联误熔断 -
MaxRequests别设 3 或 100：低流量服务设 5～10，高流量设 20～50；Timeout应略大于下游 P95 延迟，而非固定 1s
降级逻辑写在哪？Controller 还是 Service 层
降级必须写在 Service 层，且只对 transient error 生效；Controller 层只负责接收 fallback 返回值并统一序列化输出。
- Controller 里禁止出现
if err != nil { return fallbackData() }—— 这会让降级和业务错误混在一起，掩盖真实问题 - Service 方法应明确拆分为三段：
doRealCall()→handleTransientErr()→fallback()，其中fallback()只读sync.Map或本地 JSON 文件，绝不发新 HTTP 请求 - 常见翻车点：在
fallback()里调http.Get("http://cache-service/xxx")，主服务挂了，缓存服务也跟着压垮
真正难的是边界判断：400、401、404、sql.ErrNoRows 这类错误绝不能降级，它们是业务逻辑的一部分，强行兜底会导致前端拿到虚假成功响应。
